Introducing Healthcheck, a Physician for Drupal 8

IVAN STEGIC: Hey Everybody! You’re listening to the TEN7 Podcast, where we get together every fortnight, and sometimes more often, to talk about technology, business and the humans in it. I am your host Ivan Stegic. We spend a fair amount of time at TEN7 building software that makes our clients and their users lives easier. In so doing, we end up creating things for ourselves that make our lives better, faster and less mundane. And, we inevitably end up contributing these things back to Open Source. You could check out ten7.com/wegiveback for more info. on things like Flight Deck and Starbase and other things we’ve built and given back and continue to support. Today, we’re announcing the beta release of a new Drupal 8 module we call Healthcheck. And, joining me now is the principal architect and maintainer of the module, Tess Flynn. Hi Tess.

TESS FLYNN: Hello.

IVAN: We’ve been spending our fair share of time talking to each other on the Podcast lately, haven’t we?

TESS: It does seem to be a running theme lately. I’m surprised you’re not sick of my voice yet.

IVAN: Not at all. I have a lot of fun talking to you. So, another module in the Drupal 8 ecosystem. Can you give me a 30,000-foot view of what Healthcheck is?

TESS: I like saying that Healthcheck is a bit like a doctor for your website. It sits in the background of your website and runs periodic checks on the health of your site.

IVAN: And, why is the health of your site so important?

TESS: Mostly because we spend so much time not looking at it. How often do you actually look at your own website? Do you check to make sure that it’s working correctly? That you didn’t make some change without thinking or in desperation, or when you were in the wrong browser window, thinking you were looking at a different copy of your site, and now something is amiss. How often does that happen? A lot of organizations, a lot of people don’t really spend a lot of time looking at their site. To them it’s just a thing that works until there’s a problem, and then once there’s a problem, we don’t know for how long it has been a problem, because someone had to go through the effort to complain about it. Or, someone internally had to stumble on it themselves, because who knows how many users it had affected in the meantime.

IVAN: I think you’re indirectly answering a question I was going to ask, which is, doesn’t Site Audit module already do this? But, what you’re kind of implying here is that, Healthcheck does this Healthcheck of the site, but it does it repeatedly.

TESS: Yea, Site Audit is more of a point checker. I mean, it’s in the name, Site Audit. And, when you do an audit, you’re not going to have an accountant come in and manage all of your finances. You’re going to have an auditor come in and rifle through all of your paperwork at once, to actually figure out what’s going on, and then once the audit is over, they’re gone, they don’t come back. Unless if you have reason to request or require another audit. So, the whole point of Site Audit is to do a point check, at one point in time. Healthcheck doesn’t really have that kind of mentality. It’s mentality is that it checks continually, on a regular basis, and it is meant to constantly monitor your site.

IVAN: And, unlike Site Audit, it’s a module, right? Site Audit is this drush thing, but Healthcheck isn’t?

TESS: That’s correct. Site Audit 2.x is actually a drush command, and it is meant to run as a point check, whenever you run the command. However, Site Audit 3X is actually supposed to be a Drupal 8 module. Now at the time of the recording of this Podcast, it’s not yet finished. So, I don’t know where they are with the development of that, however, it might be out by the time you listen to this.

IVAN: So, basically, you go to drupal.org, you go to the Healthcheck module, it’s for Drupal 8, you download it, you install it like you would any other module, and then you go to the reports page. Does that sound right?

TESS: That’s correct.

IVAN: And, can you tell me about the reports that it generates. I kind of get the, like a very high level, it gives you thumbs up, thumbs down, and thumbs somewhat down. So, things that are good, things that are bad and things that you should check. Is that about, right?

TESS: No. See, that’s one thing that is also different with Healthcheck. Healthcheck doesn’t really try to go against an idealistic bottle of what a Drupal site should be. Instead, it has kind of an action modality. So, each individual check has to report results on how you should resolve that problem, or not. So, is this a critical problem? Should you drop everything and immediately go and fix it. Is this something that you probably should do something about, but it’s not literally on fire? Is this, “well this might be ok, and you should probably look at it, but we’re not sure if it’s actually that bad. It might be good for your site.” Or, “this is fine, this is perfectly expected. Don’t worry about it.”

IVAN: And, who determines that? Is that something that you decided right at the beginning with the rest of the TEN7 team? Or, is that something that’s configurable? Those different levels.

TESS: So, right now, the checks are actually kind of hard coded. I would actually like to someday, make this a little bit more rules based, where you could configure those thresholds individually. I don’t see why the current architecture couldn’t do that, but it’s not in the module right now. We’re still getting towards that data.

IVAN: And, what kind of checks does it support right now? And, how do those compare to something like Site Audit, for example?

TESS: So, there are a lot of similar checks between Healthcheck and Site Audit. We check a lot of best practice things, like, we check if CSS preprocessing is on, what’s your caching configuration? We do a few other things as well. We check the size of the database, if there’s, oh geez, there’s so many of them that I can’t quite remember them all right now, I’d have to look them up.

IVAN: So, basically, it does a ton of things that you’d expect from a best practices point of view, a Drupal site should be doing. And, then, it does that on a schedule, and I would imagine that’s configurable?

TESS: Yep. The schedule can be configured to run along certain periods. I think by default that’s once every 24 hours, but you can actually configure it to run a Healthcheck on every cron run, and then whatever period you have cron configure to, it can run a Healthcheck.

IVAN: So let’s talk a little bit about how it knows that there’s a difference, compared to the check that it did last. Does it only store the last check?

TESS: No. What it actually does is that, the default mode of Healthcheck is what I call ad hoc reports, and what happens is that, out of the box it doesn’t do any checks in the background, it doesn’t send notifications, all it does is provides a report screen that you could interactively check. Now, there are ways of extending that afterwards. You can actually configure it to run notifications regularly, in which case, additional options show up for how often you want that check to be run, and how do you want to be notified of when that occurs.

IVAN: And what kind of notification system exists right now?

TESS: Right now we have two different notification systems built into the module. We have one for sending email notifications, and the email format is actually configurable, so you can change it to be whatever you want, And we have one that uses webhooks, and we’ve tested it with Zapier, I’m not entirely certain if it will work for other integration providers, but via Zapier, you can get to something like Slack.

IVAN: And that notification system to Zapier is really a JSON object that gets posted to a particular endpoint, and then whatever system you’re using as that webhook endpoint, can process that data and do whatever it wants with it. So, something like Integromat or Zapier, or any of the other competitors will likely work with this endpoint. Ok, so, if I understand this correctly, Healthcheck is a site doctor for your Drupal 8 website. It runs and can run on a schedule, it keeps a history of all the checks that it’s done in the past, and it compares the latest check with the previous one. It will then alert you either via email or via webhook as to if there have been any changes. Does that sound about right?

TESS: About. It doesn’t really check the previous one to the next one. There are mechanisms where if a critical item is found, it will run notifications no matter if that was previously discovered or not. And there are configurations to run regular reports and send an entire digest of all of the findings that have been found in the last Healthcheck to whatever notification system you configure it to.

IVAN: That sounds like a patch request. If someone’s out there listening, you can submit your own patches, we can absolutely add the feature of being able to check from a previous, do a comparison from a previous check, so that you’re only sending notifications out when something changes. Although, I’m not sure that that’s any better than sending it out every time cron runs. If you haven’t dealt with an issue, you probably, especially if it’s critical, you probably want to be reminded that something’s going on.

TESS: Yea, that’s generally kind of where it came down with the situation. It’s not like a phone notification, where once you see it once, you don’t want to see it again. This is an infrastructure notification, and it’s kind of common practice that you don’t want those to get deprioritized. You want to have that priority regularly refreshed, so that you know you have to deal with it.

IVAN: That. That makes a lot of sense. So, this is in beta release. It’s the first beta release for Drupal 8. So, basically, Healthcheck’s been written from scratch. Is that a good thing?

TESS: Some people say that it’s never a good thing to write a thing from scratch. Honestly, in my perspective on Drupal 8 is, you might as well write from scratch. And, the reason why is, Drupal 8 is fundamentally a very different system than Drupal 7, and it is a false dichotomy to assume that they’re really the same product. They’re completely different in my opinion. And, if you don’t take the time to reconceptualize what you’re doing from 7 to 8, you’re going to have a bad time eventually if your module is of any degree complex.

IVAN: So, let’s talk about the Drupal 8 version of this module. I want you to mention, and maybe kind of talk about how the plugin architecture has been designed. The idea behind it is that we are going to release a module here that has a certain amount of capability to do the checks that we really wanted to do. But then, make it possible so that anyone can write their own checks in addition to the ones that we’ve written. Does that sound about what we were thinking?

TESS: Yea. One of the primary concerns for me, when I was architecting this module is, I wanted to make it really, really, really, really, really easy to write your own checks. I don’t want to make that a complex, weird affair, I wanted to make it as natural as possible, for anybody who is used to implementing a Drupal 8 plugin. And, with Healthcheck, we already provide a base class for the plugin. We provide all of the documentation, we provide the plugin types, there are easily findable examples within the module that you can pattern it off of, and really you have to make one object and one function, and that’s it.

IVAN: Is there a limitation to the kind of check you could be writing?

TESS: Well, ok. There are a few things that do come as a limitation with the module-centric approach. One is, if the Drupal environment is completely non-functional, this module probably won’t work. And, that’s going to be a bit of a limitation for some people. Also, you can’t run it as part of your infrastructure hosting. So, you can’t have this as a command floating out there as Site Audit does, where you can configure the infrastructure to regularly run it against any directory that you assume has a Drupal installation somewhere. With Healthcheck, it’s limitation is that it is a Drupal module, so it only knows about your Drupal site, it doesn’t know about anything else.

IVAN: How does that affect whether you have a multi-site installation or not?

TESS: So, you can still install Healthcheck in the module directory, and have it available for all of the sites in the multi-site, but you have to enable it for each.

IVAN: So the beta release that we’re announcing today is for Drupal 8. There’s still a ton of Drupal 7 sites out there, and I know we’re planning on providing support for Drupal 7 as well. Can you speak to how that may be the same, or might be different than the Drupal 8 module?

TESS: So, I would like to write it as similarly as possible, with similar class names, similar interfaces, so that it works more or less the same. I would like to use C-tool plugins, but I also have no experience with C tool plugins, so I have no idea if this is a good decision, or even the right one.

IVAN: But we’re going to find out, because that’s how things evolve, and that’s how we learn. So, I’m looking forward to finding it out. Are there any other options to using C tools?

TESS: Well, you could write your own plugin manager toolkit, but it’s like, that’s a little bit…I’m not looking forward to that task myself if I was tasked with it. (laughing)

IVAN: (laughing) Well, we might have to have you architect it, and we’ll see who else we can get to help us do that. Ok. So, Drupal 7 version coming soon, hopefully in the beginning of 2019. As some of the listeners out there know, we have a service called TEN7Audit, which is usually the first step of onboarding a new client with TEN7. And typically it’s for a client, for a site we didn’t build, but might need Drupal support, and in the past, we used Site Audit to extract useful information about the site, kind of just as a cursory look. The very first thing we do in a TEN7Audit is run Site Audit, we get that initial automated list of things to check, but now we’re using Healthcheck as a drop-in replacement for it. There are obviously things that Site Audit does that Healthcheck simply does not, and I guess the question for you, Tess, is, when is it more appropriate to use one over the other?

TESS: Usually when it comes to running the individual Site Audit, usually I’m only concerned with one site, and so far, I haven’t actually run across any multi-site installs. I’ve run across a few domain access module installs, and also custom implementations which mimic that kind of behavior, but not a multi-site qua multi-site, yet. And even so, it could be run on it, it would just require a little bit more effort. And when it comes to when should you run Site Audit, well, for the moment we don’t have a Drupal 7 version of Healthcheck, so, I would say that anytime you’re doing Drupal 7 stuff, you should probably use Site Audit for right now. Also, if you intend to run this as part of an infrastructure setup, inside of server hosting, or containers that regularly run against your multiple installed sites such as if your….I know that Pantheon does this, I know that you could definitely configure Site Audit to work with Aegir, that is one possible usage of it, those are definitely good options to use Site Audit for versus Healthcheck. Healthcheck is meant to check just one Drupal site.

IVAN: Ok. We kind of started talking about future features in my mind there, so, maybe after the first beta release and the first stable release, we’ll focus on doing some Drupal 7 implementation of Healthcheck. But, maybe a future release, or have you thought about a future feature in subsequent releases to enable some sort of CLI interface for Healthcheck? Or do you feel like you don’t want to take the module down that route? Do you feel like you just want to continue to have the module be a module in the classic sense with the UI and not go down that CLI route?

TESS: The problem with the CLI route is once you go down that path, the question is, whether or not it’s going to maintain being a Drupal module, or if it’s going to be a Drupal orbiting command. Site Audit really isn’t a Drupal module, it’s a drush command. It’s what I would call, a utility, which is in Drupal’s orbit. But, Drupal itself doesn’t need to be functional. And, when you look at Site Audit internally that actually explains a lot of the design decisions that go into it, why it doesn’t rely as heavily on internal services provided by Drupal to do a lot of checks, but Healthcheck does.

IVAN: So, likely, no CLI coming to Healthcheck in the future.

TESS: Well, we can still add one, it’s just that it wouldn’t be a pure CLI approach. It would be an adjacent command which would allow you to run the checks, and even get those responses. I had thought about implementing that too, as a drush 9 command, and a Drupal consult command, But at the moment what you would usually do is, you would run drush cron and that would run the Healthcheck for you.

IVAN: The thing that made me nervous is when you said, “once you add it, you won’t be able to take it out,” and you’ve gone down that path. So, now I’m a little bit hesitant about adding the CLI to Drupal 8 Healthcheck. I kind of like the idea of just running drush cron and having it run Healthcheck.

TESS: I mean that already works. That’s how I was testing it. (laughing)

IVAN: (laughing) So, the other thing that appeals to me is, this idea that notifications or reports can be sent using a webhook, because that opens the module up to being used in so many different places as well. And, the thing that I am looking forward to is this idea that we could potentially have a dashboard where we can see all of the sites that we’re checking for clients of our own, the multi-sites, whatever they may be. All Healthcheck sites in one place, to see kind of the status across the board. Do you think that’s a reasonable expectation?

TESS: I would love to write that functionality because it would allow us to collate a lot of different reports from Healthcheck, and then take them into a single dashboard that we can display using views.

IVAN: I love that idea. And then maybe we could start to service online and other people can sign up to using it, and we will become a service provider then. Anything more you want to say with this beta release of Healthcheck?

TESS: The thing that I really like about Healthcheck, is that, it is intended for people who don’t have a comfortable grasp of the command line environment. They’re used to modules, they’re use to working with the Drupal admin Interface, and Healthcheck really shines there. It’s meant to be accessed and worked from, from that interface, and allow you to do all of your checks from that interface. And that’s what I really, really like about it.

IVAN: And it’s also created by an incredibly talented amazing, developer on the TEN7 staff. Thank you so much for all the work that you’ve put into it, Tess. I’m looking forward to getting a stable release out there soon after the beta, and maybe you’ll join me again when we add another major feature to Healthcheck.

TESS: Yep, sounds good.

IVAN: Healthcheck is a Drupal 8 module, available now in beta at ten7.com/healthcheck. It’s you’re your site’s own personal physician. It’ll periodically run checks on your site to see if something’s changed, gone wrong, or been misconfigured, and it’ll also alert you. Drupal 8 Healthcheck at ten7.com/healthcheck. You’ve been listening to the TEN7 Podcast. Find us online at ten7.com/podcast. And if you have a second, do send us a message. We love hearing from you. Our email address is [email protected]. Until next time, this is Ivan Stegic. Thank you for listening.