 Okay, good afternoon. Welcome to How to Audit Drupal Sites. Thank you all so much for coming. This is a fantastic audience. I deeply, deeply appreciate it. My name is John Peck. I'm a software architect at Four Kitchens, a digital agency based out of Austin, Texas. I can be found on the internet on a number of different places, including GitHub and Drupal.org. I've been working in Drupal for quite a few years. I've worked on projects such as the architecture of Entertainment Weekly, People Magazine, successful farming, I've done performance work at a number of organizations, and including Time working at Pantheon as a senior customer success engineer, and among those responsibilities was bringing people onto the platform and making sure that their sites were performance. And you can kind of probably see a little bit of where the genesis of this comes from. So what is an audit? Audits are more than just words. An audit is an official inspection of accounts. An audit isn't necessarily a dirty word. It's where you can actually validate some of the good things that you're doing. It's good to be told that it's like what you've done is the right thing, or at least adheres to something that people agree with. And also can highlight areas of improvement. We're made of meat, we make mistakes, and having something saying, oh by the way, on this incredibly complex system with literally hundreds of thousands of pieces of input, you missed one. Having something to actually say is like, hey, this is something that you can change, or possibly this is a little bit out of alignment. You may have done this completely on purpose, but you should be at least educated to that this is out of the norm. So why should we do this? Auditing sites, you do it for a number of reasons. Sometimes it's just purely performance. I wanted to make sure it's faster. Sometimes you want to learn about the contents and the structure of the site in kind of a normal way, in saying there's gonna be, I have these expectations around it. Also ensuring optimal configuration, making sure that it's ready for production, or it's configured appropriately for a development environment, making sure that you're not doing things that are suboptimal and taking longer, for example. And also, again, to find areas of improvement. So within the context of Drupal, we're all unique snowflakes. Every site is unique, but it's all built in the same framework. So we're all using version of Drupal, either six or seven or eight or five if you're glutton for punishment. But they all have similar architectural requirements, a lamp or a lamp stack, or you can use a PostgreSQL or MSQSQL, but at the end of the day, it's a pretty similar stack. And therefore, one size fits most. There's things that, obviously, there will be exceptions to the rule, but it's good to know that, for most cases, this makes sense. So there are a few hallmarks of effective auditing. Things such as providing consistent responses every time. You run a test and you expect to get the same results, like saying, okay, what color is the sky today? Blue, and if you run it just a second later, assuming nothing has changed, you're expected to be blue. If it says blue one time and then orange the second time and it hasn't actually changed, well, that's not really an effective audit. It needs to be quantifiable. So something that's really frustrating, especially when you're trying to work on a site and someone says, the site's slow, and that's it, and it's like, mic drop, okay, what do I do with that? Well, how is it slow? It takes 10 seconds for the front page to load every time. Oh, okay, that's something I can actually work with and that gives you a benchmark, something that you can improve upon. It should be contextually aware. For example, this is a development environment. I'm not gonna yell at you for having development modules enabled. This is a production environment. I am going to give you a hard time about it because it's not appropriate to have that kind of thing around. It should be easy to understand. Don't baffle them with BS. Actually give them something that's clear and actionable. This is what you need to do. So for example, caching is turned off. Explain that in plain language. I mean, yes, you can obfuscate it with really fancy terms, but at the end of the day, caching's off. Say that. And then finally, provide actual recommendations. This is what you need to do. No one likes to know that they've done something wrong, but they do want to know how to fix it. If you just say it's like, this is terrible and then just leave it, nobody wins, nobody improves. And why would you do that? So this is gonna be kind of a tool-oriented approach because again, like in the context of Pantheon and just in general, working on multiple sites at any given time, I look for ways to be efficient. And being efficient means coming up with a repeatable process. So some of that is a tool-oriented approach. Jody of ZipTech has a fantastic version of auditing which is more content-oriented and actually gets more into the semantic content and the IA of it. And it's a fantastic presentation. She did it at Bad Camp and I highly recommend checking out that presentation as well. So with that said, first tool that I'm gonna talk about is Site Audit. This is an open source project, it's available on Drupal.org and it's a Drupal 7 and Drupal 8 site analyzer. Looks for a number of, it looks at the content, it looks at the configuration and it provides report. In its current state, it's a Drush command that runs on the target platform. It's not actually installed in the site itself. So it can be, but it's kind of shoe-horny and it's not a module, so it's not something that you enable. And it powers launch check, well specifically launch check for Drupal on Pantheon. So what does it report on? Well, there's a number of different things. It's things such as best practices, which is mostly kind of configuration kinds of things, like how is the site laid out? Have you tried to mess around with a structure of putting sim links in weird places rather than adhering to the normal Drupal structure, which makes it harder to maintain and sometimes can introduce performance problems? Looks at the block module, is it enabled? Is caching enabled? What caches are available? How it's configured? And then the caching system itself, such as what are the cache backends that are being used? Are you using something that's inefficient? If something like Redis is available and you're not actually using it, it'll give you a recommendation around that. The code base, certain kinds of metrics such as how large it is, the size on disk, some information about the repositories that are contained within it. The content, so it isn't doing semantic content analysis, but it is actually looking at the structure of it. So how many content types are there? What are they being used? What fields are there if those fields are being used? Do you have empty fields, for example? Also, that goes into taxonomies and vocabularies as well. Cron, so what cron runner you're using, if any, and it'll make a recommendation, basically, you should be using some sort of cron. It doesn't have to be poor man's cron that's built into Drupal, but it should, that regularly scheduled process should be executed in some manner in another. I'd also tell you if it's stuck. So it'll also look at the database, like the number of tables that are available, the size on disk, it'll give you, there are optional reports that will tell you it's like any rows, database tables that are over x number of rows. So if you wanna say, show me all the database tables that have more than 100,000 rows, that can give you kind of like an idea of what some of the outliers may exist. The extensions, so that's modules and themes, what's enabled, it does a number of interesting little checks for, you can't get away with this in Drupal 8, but in Drupal 7 you can get into a situation where you enable a module, remove it from the code base. Drupal will still check for it until you actually uninstall it until it know this module no longer exists and actually puts Drupal into a really kind of slow error state. Also checks for duplicate modules so that are outside of profiles. Having an installation profile with a module and overriding it is normal, but say if you have two copies of C tools in sites all modules for example, it'll yell at you and say this is not a good idea. It is multi-site aware so it should be smart enough not to give you a hard time about that. Front end, so it's not actually look, it doesn't directly look at the front end, it integrates with third party services such as webpagetest.org or Google PageSpeed Insights and if the site is accessible from those it can actually run those given an API key and produce those results in a consistent format. Security, so as it's been pointed out there is no 100% perfect secure configuration and you should never look at a security report saying yep, it's done, but you can at least know a couple things they're taking care of. For example, built into Site Audit is a check for malicious callbacks in the routing system, things like exec for example that basically would only exist if there was either a very malicious or very incompetent entry that would allow arbitrary code execution on the system. System status, Drupal itself is actually really good at telling you what's wrong with it. Some modules are better than others about telling it but Drupal Core itself actually has this great system page. This surfaces it in a consumable fashion. The users, so basic information such as who is user number one, who is number six. How many roles exist on the system? What kind of, who has elevated permissions? How many blocked users are there? Have you blocked user number one? Some people recommend that, other people don't. It's not an error, it's just a kind of a statement of yes, you've done this. Views, so is views enabled? Okay, if so, goes into views caching. So views has two different kinds of caching. There's the render caching and the query caching and it'll make a recommendation that's kind of contextually aware. So if it won't give you a hard time for admin views but if it's just a regular view without views bulk operation, you should have some type of query caching on it. And the render caching actually should just be as long as possible because as soon as the query changes the render will update automatically. And then finally, watchdog. Do you have DB log enabled? How about syslog? Okay, well DB logs enabled. I can actually look through the content and see it's like, oh yeah, by the way you filled that with a whole bunch of PHP errors. You should probably do something about that rather than just ignore it or turn off DB log because it makes your site slow. So site audit is not a panacea. It doesn't actually do everything. And if you're ever in San Francisco this is a fantastic club. But anyway, site audit does not check the usability or site experience. These are things that humans are really good at doing. There are tools that exist to help it. This is not one of them. It also doesn't care about the aesthetics of the site. You can be gray on red with flashing blink tags. It doesn't care. I don't care. Make a statement in whatever way you want possible. This is only looking at the configuration of the site. It's like, if you want blink tags and you want to serve it as fast as possible, use site audit. Also, it doesn't check for semantic content. There's actually a few exceptions to that but not within site audit itself. So it doesn't care what language the content's in. It doesn't care what the subject matter is and it doesn't have a practical way of analyzing that. So site audit has a built-in manual because nobody wants to ask questions. So Drush help dash dash filter equals site audit will actually give you a list of all the available reports and also like a high level overview of what each one of them does. There's also a convenient helper called audit all that just arbitrarily runs them all. So here's an example of a report. This is the audit cash report and you notice a few things about it. Like right at the very top, I mentioned having as a quantifiable thing. So right up front it says Drupal's caching settings 17%. So percentage is a scale of 1 to 100. People understand that it's like 17%. That's kind of bad. You actually kind of want that higher up. So right up front you have a number. Each time you run this report you are going to get a number and that number can be used to determine success. Like have I fixed this problem? There's that number going up. Next up is anonymous caching. Anonymous caching is not enabled. That's a problem. So it's done a check. It has a response to it. It's an exceptional situation and then it gives you the actionable recommendation outside of that. Go to admin, config, development, performance and check cash pages for anonymous users. Sure you could set a variable but this is the easiest path. This is the fastest way to success in this context. And it has a couple more errors that are very similar. And notice that this only provides the list of what's wrong. In its default mode it's not verbose. The next version of it is the detail mode where it actually will go through and tell you the things that are good in addition to that things are bad. Sometimes I just want to know what I need to do to fix it and then other times I want to be validated and know that these things are where they are. So dash, dash, detail will give you that context. So for example, minimum cash lifetime. Minimum cash time is set to null. Expiration of cash pages is not set. Oh that's an exceptional situation. Once again you get the recommendation. It'll also produce JSON output which is probably a little small on that screen. I apologize. But it is actually a bunch of nested data. The JSON output is actually really useful if you're writing tools that integrate with this. For example, launch check uses the JSON output from this and parses it. There's been some relatively recent changes to the JSON structure of a couple reports that takes out the HTML and actually properly nests the JSON so to make it more consistent. It also will produce HTML output which is a little bit more human readable if you want to kind of surface it well for people who like reading things that aren't on a console. So here's an example of best practices that are actually looking good. And then finally, audit all has an option for using Twitter Bootstrap. Regardless of what your opinions are of Twitter Bootstrap, it is a system for styling. If you don't want to use it, you don't have to. But it produces a summary along with some color coding, just basic color coding, you know, green is good, red is bad, gives you that kind of executive summary right at the top. Here's everything that is good and bad and then we'll actually iterate through those who can navigate through the report. This is something that you can actually put in front of an end client or end user and while they might not necessarily understand every single one of the recommendations, they do understand, it's like, hey, these things that are red that have low scores, these are probably things that should be addressed. So site audit does try to do a lot of things. It doesn't try to fix everything. There's certain kinds of scenarios where I don't feel it's appropriate to get into, such as doing kind of like a whack-a-mole, kind of like looking for like a blacklisted, particular function name for example or a malicious username that is common and say something like Drupalgedin because the best way to defeat that is to change the username. I'm not gonna play that game. Therefore, it doesn't make sense. But other modules can. So modules can implement both checks and reports. The checks are just kind of like the atomic, like a unit test, checking for a particular thing and then a report is a collection of those checks. There's documentation in the README and also the module itself, there's abstract classes that you can just extend and should be relatively well-documented. If you'd like to, if you have a particular request or if you wanna know how to work with it, just go to the Drupal.org issue queue or also provide a GitHub pull request if you are feeling so inclined. It's the projects up in both places because different people have different workflows. So if you've written one, please, this is an open-source community. We all gain from working together, regardless of your context. Yes, we're all specialist snowflakes, but the probability is if you've written a test for something, it's probably applicable in a greater context. Please do share your checks and reports. Honestly, dozens of organizations and individuals have contributed to site audit over the years and it's absolutely fantastic and has helped grow the ecosystem. So please be a good citizen and share. So as site audit development continues, I've been very interested in Drupal Console, which is a Drupal 8 command line interface. I've been working to make a Drupal Console version available, this doesn't mean the Drush version is dead, it just means that I'm extending the availability of it and also making a little bit less tool-specific. So the eventual goal is to have one-to-one feature parity just depending on how you run it. If you wanna run it from Drush, it doesn't care if you wanna run it from Drupal Console. So, but it is up and running. I'm a human, if anybody has some time that they wanna help, by all means. So, I mentioned that site audit can be extended and actually there's a number of tools with site audit support. You can use it in conjunction with site audit or you can use them as standalone tools, both of which are completely valid options. Unused modules is an example of that. It is a system that does exactly that. It looks for modules that have been disabled in the system while either disabled or uninstalled that don't have any additional dependencies. For example, views and views UI. It won't give you a hard time about because you can have views UI off but views is actually active. So there is a dependency that is required and therefore it's not going to tell you to uninstall views UI. So the nice thing about it is it can help reduce the size of your code base which just makes it easier either like if you have a build process making that build process shorter or if you're just maintaining a single monolithic site, less is more. It's easier to not have to wade through things that aren't being used. Right, mentions that. Security review, another fantastic module that does checks for site and hosting configuration and also checks the site content and actually like scans and gives you actual recommendations, things like checking for PHP files in the Drupal files directory making sure that the web server no matter what it is can't actually allow someone to execute that which is a huge security vulnerability or checking for untrusted roles having administrative or trusted Drupal permissions. So it surfaces those reports. I should have checked this before this presentation. There is a Drupal 8 version of security review. I don't know if it works with Site Audit. We'll find out. Hacked is another wonderful module. Right now there's only a Drupal 7 version. I think there's something in the issue queue for Drupal 8 but actually that screenshots from Drupal 6. So well, because that's their screenshot. But what it does is it does a comparison between the version of modules that you have installed on your site and the version that is available on Drupal.org. Why is this important? Well, if you don't have your things in version control you should and you should feel bad if you don't but if you don't it can actually do kind of a comparison and give you at least a little bit of sense of certainty that this code hasn't been modified. Also, and more commonly, you wanna know whether or not someone has actually played around with the module either patching it or just making an arbitrary change that next time you update the module will be wiped away and bad things happen to your site. Sensitive data is actually a brand new module that I found out by sitting at the sprint table. Which is fantastic. It is actually, to the best of my knowledge, is the first standalone site audit extension that isn't a module that I'm aware of. It searches content for sensitive information such as credit cards or ID numbers. So it actually kind of looks over the entire, basically every single piece of content and looks for a sense of information then does a more careful check to make sure, within PHP to check for known algorithms and it's continuing to be evolved. So check it out, I think it's cool. Cash audit, so site audit does audit caches and there's actually fair amount of crossover between the two, but it reports it in a much more granular way so it checks the caching settings of Drupal core, block and views and panels. Now panels is different because site audit does not actually audit panels, just didn't get around to it. And so it's a great tool and provides some really cool recommendations. So now we're gonna start getting outside of Drupal specific tools. This is kind of related. PHP Code Sniffer is a tool for tokenizing your PHP code and checking for coding standards and other types of PHP standard violations. The Coder Project, which is on Drupal.org integrates with that and provides rules that are specific to Drupal. So believe it or not, no matter if you have a Drupal 7 or Drupal 8 version, use the Drupal 8 version of Coder in conjunction with PHP Code Sniffer that contains the latest and the greatest Drupal coding standards that will apply to both 7 and 8. And it contains both Drupal and Drupal practice SNFs which are best practices. And yeah, it automatically detects deviations from Drupal coding standards. I'll take a step back for a moment and say whenever you use a tool like this on an existing code base, unless you're a robot or you're very good about setting up like something like Editor Config that enforces tabs versus spaces or indentation or rules, you're gonna get a lot of results. Don't try to fix them all at the same time. It's a micro-optimization that makes everything really difficult to work with. Instead, take kind of an incremental approach to just clean up like whatever you're working on and over time make the entire site better but don't try to do it all at once. That's not a useful use of anybody's time. PowerReview.sh is actually, oh, I should have put this in a different section. Anyway, it's a hosted utility that runs Coder and actually runs some other utilities on contrib modules. This is also part of the module application process if you want to become a module maintainer and actually be able to post projects on Drupal.org. I think right now it is a hard requirement that you actually put your sandbox module through this process and it provides automated reviews. So some PHP specific utilities. PHP copy-paste detector does, well, exactly that. It looks for large blocks of repeated code that you should probably be consolidated. Developers shouldn't be held accountable for, they should be delivering functionality not necessarily producing as many lines of code as possible so this will help detect kind of weirdness. PHP mess detector also looks for just badly structured code or things that have really ridiculous kind of nesting and complexity to it. Suboptimal code and over complicated expressions or some possible bugs which there's crossover between those and some other tools. PHP lines of code as I mentioned earlier, well, counts lines of code but also will give you a report on namespaces used for example and give you just kind of an overall perspective into the site and measures the size and structure of the site. Git also has a wonderful history so before I even like mention any tools, this is a graph from a very real world site and utilities such as, a hosted platform such as GitHub for example also will surface a view very similar to this. When do you think that that site was really worked on and by an agency and then hand it off to a single developer? This helps tell a story. It's not the entire story. I mean there's a lot more nuance in it but it helps give perspective into what happened over the life cycle of a project especially if you're adopting a site or you just want to know what the heck happened to this over time, this is one of the perspectives. So Git stats which is on GitHub and Git Inspector both produce kind of similar results. Your mileage may vary. Take a look at the, it'll also get into the activity of individual contributors so you know whether or not like oh so and so put 100,000 lines of code in the database or into the code base. Well that's interesting. Was that needed? And then they immediately removed 100,000 lines to the next commit. Oh okay, that happens. So JavaScript tools. So ESLint, this is actually available from eslint.org. There's a definition that is actually within the Drupal 8 core that actually similar to Coder, those standards and those standards and configuration apply both to seven and eight but it's a pluggable linting utility for JavaScript. So basically make sure, does it function, does it adhere to coding standards and best practices. There are other utilities that do something kind of similar, JSCS which is JavaScript coding standards or code style rather. It does exactly that. JSCint also will get a little bit deeper and detect errors and potential problems. There's a little bit of a community in fighting about like what's better, ESLint or JSCint and why don't they merge? Well they take slightly different approaches so those are both options. Drupal 8 core has an ESLint configuration so take that as you may. There's also some utilities that are available that aren't necessarily installed on the platform or whatever you're using such as webpagetest.org. It's a fantastic utility, does two requests, one after another I can actually do a request as a specific browser for example or a mobile device which is wonderful. It'll gives you some of the hallmarks of what I consider a good audit in which gives you like these really a combination of like this is F on a scale of like A, B, C, D, F, it's like this is really bad or X this doesn't apply and also the coloring to like really highlight hey this is bad but also gives you a sense of like whether how the caching configuration is working. For example like the first request on this particular example, 748 K for the first time, second time 111 K. Okay cool so at least a few things are caching. Better, less is more obviously and the 700 K is still kind of big. How can we improve that over time? It also produces a wonderful waterfall view and a number of different, it makes recommendations around the use of CDNs and also setting your cache timing in an optimal manner. Google page insights actually has, is kind of a user friendly version of this. It provides a number of the same recommendations not necessarily with the same granularity but it's still a really important tool and also more importantly these actually does, making this page happy has this weird side effect of making your Google page rank a little bit happier as well. So pay attention to this one as well and also gives you like these actionable recommendations and also will surface problems like such as okay you're using this third-party tool here's this caching that should be applying to this third-party tool that isn't there and you don't have direct control over that. That's, it'll surface things like that and then you talk with that vendor and say hey by the way you really should be caching this otherwise my site is slow and why should I keep giving you money. Another utility that does a different kind of analysis is the Wave web accessibility tool. It's available at wave.webname.org. This is actually this particular session did an analysis so it analyzes web pages for accessibility kind of best practices and checking to see like do you have proper alt text for example like in this example these don't and also provides you actual recommendations on what to do about that. Accessibility is very important. It's not only for people who need assistance accessing content it also helps robots and crawlers actually consume the content of your site and also just produces a better structured experience overall if you can actually use some of these recommendations. The Qolsys SSL server test does exactly that. It looks at your HPS configuration actually looks at the certificates in this particular case it gets a giant F because this particular site has a bad, has a known vulnerability in their certificate and so it gives recommendations around that. Run it on your own site this is actually this doesn't making that an A doesn't mean your site is secure it just means it's secure from these particular vectors at this time. Run it every once in a while just make sure that you're up to date and using the current recommendations. So this is a lot of information it can be kind of overwhelming and it's really tempting especially when you have tools that can produce pages and pages of content you're just like look at this boom I have delivered all this value to you done bye. This isn't good so when you're actually like providing a report even if you're just like doing it for your own purposes like have some decency and actually kind of structure it a little bit. So a decent report structure should have just kind of like a brief overview of like what the scope and the requirements are is like okay the scope is like hey we wanna know how the site is what site is being looked at what portions of the site as who like maybe as an editor I wanna go through these things or as an anonymous user I wanna like look at the list of latest news and what the requirements are for the project and also providing the actual recommendations get to the point what actually needs to be done don't baffle them with BS actually just tell them it's like hey this is what needs to be done or this is what I'm going to do or have done in order to rectify these problems. And then having the output from the tool is great stick it in a pen it stick it at the very end of it so it's like if you really wanna check my work if you wanna know how to do it how to install these tools and do it yourself because these are all open source or at least publicly available utilities don't hide that information actually exposed to the client yes this can be a little bit dangerous if they get hyper fixated on a particular metric but it at least gives them an opportunity to be able to understand how the changes that either you or their team is making on the site what impact that has and also help surface things is like hey by the way people aren't going to your site because it's really heavy and here's this tool that tells you how heavy your site is and you can see that for yourself it's not just me saying it. And also provide the raw results because you want to say okay hey back in 2014 your front page downloaded 10 megs of resources now in 2016 500K okay fantastic you can see that change over time it's also you know if you run the same kinds of tests those the results of those tests you can actually use that as comparison it's like okay Google page beat insights used to be 40 now it's 90 okay that's a quantifiable difference I can measure that and if you don't actually store those results you aren't able to make those comparisons. One of the utilities that I recommend I mean your mileage may vary you can do it in all sorts of different ways but Gitbook is an open source utility it's also a commercial product so use whatever you find works for you but it's a book format and tool chain for using Git Markdown Markdown is a simple text formatting syntax that you can use it's a command line tool out of the box that uses Node.js there's also there's actually GUI tools available as well from Gitbook that will allow you to use it as what you see as what you get at it or so you can just paste content in and like just mark something as bold or bullet a list and so forth it outputs HTML which is good if you want to publish it on like a GitHub page for example or hosted as PDF so lots of people like to have like give me a full report would it be great if you have like basically a click of one button or just run a command line and just here's the PDF of everything properly formatted ebook formats if that's your thing and other formats I find it incredibly useful for large structural reports because you can have basically it's like every section is a separate file so restructuring a report is as simple as just changing either the indentation or the order of a bulleted list so if you've ever tried to work with a 100 page document and say something like Google Docs or Microsoft Office or what have you that can get a bit unwieldy you're gonna make mistakes you know copy and pasting versus I'm just gonna move this one bulleted list I'm gonna reverse the sequence and suddenly the entire report is restructured so this is an example of using the Adam open source editor it works really well it has a built-in markdown preview just works but honestly this is just straight text you can use sublime or what have you to work on it and this is an example of the GitBook HTML format which you know this is what again it's very similar to a number of hosted utilities as you can see it lends itself well to documentation or well structured reports I will say just as a side note I don't think GitBook works really well for project documentation I've tried it it just it's not really maintainable there's better ways of doing it but for reports or for hosted manual GitBook is fantastic so lot of there's a lot of things that can be done I've mentioned like things like Drupal console support you know the Drupal ecosystem is continuing to grow and evolve I'm one person there's been like dozens of contributors over the years I am looking for help if anybody is interested basically submit an issue on Drupal.org and let's talk like help is fantastic and a team effort is better than one person working on things so if you're interested submit an issue so as a summary good configuration matters this is a screenshot from a site that was hosted on Pantheon and it's kind of dramatic got a complaint page is slow okay what's going on did a quick look oh your caching configuration is bad just like low lying fruit like anonymous page caching is turned off so Drupal is sending uncashable headers and so every request that comes in goes straight to the web server Varnish isn't doing its job and then you know flip the switch and suddenly everything's fine you know thoroughput request per minute go way down because it's not going to the you know web server anymore the appdex store goes way up the uh... you know at the time that it takes for the server to actually respond is lower because there's less work that it has to do everybody wins so that's it thank you very much for coming deeply appreciated uh... do you have any questions uh... we have a microphone set up over here uh... if you have a question either uh... yeah please just go to it and uh... or i'll just repeat it can you put test test is this on? can you post the slides? I'm pardon? can you post the slides? can I post the slides? oh absolutely uh... there's uh... oh well that uh... yeah the slides will be posted on uh... drupal.org they're also on uh... github and uh... yeah absolutely so have you uh... run into people using tools like site audit to do uh... regular monitoring and where do you like to draw the line between auditing and monitoring? uh... well in in some ways yes i mean uh... pantheon launch check is actually a form of monitoring and you know it runs once an hour and actually gives you those recommendations uh... i'm not aware of any tool that uh... similar to aquia insights you know keeps track of those changes over time uh... that's been something that i've intended to build but just haven't just time uh... but uh... yeah i mean especially with a structured JSON output there's no reason why you couldn't actually run those uh... run those reports on a regular basis and put it into an aggregation tool such a splunk for example uh... when you talk about why to do the site audit do you think that you don't have the point of how this affects the end users so that's that's like no part of the why so what is what is your opinion? like why is that not you know explicitly said in the presentation because i think if you have you have to need to do an audit and you're gonna put resources on that you need to explain to you i guess you team or your supervisor the people that's gonna be involved in that that's gonna be a lot of effort and especially for the business people they will need to understand why they need to invest on something like this oh clear yeah well and part uh... you know in part of the reason for doing an audit is you know some of it is to uh... you know determine uh... you know you know is there a problem you know what kind of problems there are and what kinds of impact they will have on on users for example site performance is uh... you know you know very very important to users people who uh... have difficulty accessing a site uh... you know or if it's too expensive to access a site you know for example if you're in an area using uh... you know a limited mobile plan for example uh... and there is a literal cost associated for each page you if it's going to cost you five dollars to look at the front page of a site you're probably not going to go to it or you're only going to do it once uh... so you're right there is like you're going to increase uh... your site audience if you make the site more accessible and some of that is based on uh... performance or page size uh... the uh... you know being able to put a direct monetary value on that is kind of difficult uh... but uh... if you have uh... utilities such as you know something like google analytics uh... or site ground that is actually paying attention to the site traffic and you say it's like well when uh... site performance is down the number of users has gone down and when site performance is increased the amount of participation or involvement or you know the depth of content that they actually you know the time that it uh... takes for them to bounce from the site increases and that's that is one way to measure the impact on an audience all right well thank you very much thank you for thank you for coming uh... please give feedback uh... that's a link to uh... the uh... oppose the slides there shortly but uh... yeah the Drupal Association would like feedback on these sessions so thank you sorry uh... one more question uh... is uh... site audit dependent on the pantheon launch check or can i use it in my own uh... environment no launch check is uh... the Drupal launch check is dependent on site audit uh... not the other way around so oh yeah you can install it anywhere uh... there's support for pantheon i'm sorry there's support for uh... aquia uh... no there's not support for platform.sh yet but yeah you can install it anywhere it's completely open source and you can install it anywhere uh... yeah it's platform agnostic which is fun cool