If you've ever felt like your Drupal development company isn't cutting it, here are some things to look for on your status page that will (hopefully) reassure you—or at least educate you.
Things you'll need:
- Full Drupal admin access
- A system that's live/in production (if your developers are mid swing, it's hard to judge based on a lack of completion, ya know?)
If you can actually log into your Drupal system with administrator access, there a few key things you can look for. If it's on development system, issues here are much less critical. Many times the system runs "just fine" regardless of any issues you see here. I bring them up because of that very fact: they often get overlooked by inexperienced Drupal developers who are concerned with just getting the system running.
Step 1: Check out the status page
You can find it here: (http://[your domain].com/admin/reports/status). Don't freak out if there are a bunch of red and yellow rows, many of them indicate very minor issues.
Step 2: Analyze
- Database updates. This one can actually be a pretty big deal, it can also be relatively minor. Assuming your site isn't throwing fatal errors or white-screens-of-death everywhere, this issue is probably minor on your site. Regardless of the severity of the issues caused by this, it's not permanent and it's usually an easy fix. But it demonstrates either negligence or a lack of familiarity with Drupal's upgrade process.
- PHP memory limit.
A green background on this field doesn't mean much. Somewhere in the 100s is a reasonable value here (below 100 is fine too, provided you're not getting out of memory errors). If your site requires over 200M to function, you're running a very heavy site. Typically a very heavy site indicates bloat due to bad architecture and bad development practices. Note that this value is usually set server wide, so it could be related to a different system on the server (a couple of our development systems are set here so that they can run sites like this we've inherited). If you know it's not caused by other sites on the server, this is one of the bigger red flags you can see. It takes a chain of bad decisions to need that much memory. - A couple of security checks. Both of these issues are critically important to the security of your system. Very rarely have I seen these not protected. Allowing anyone access to update.php allows random people on the internet to run updates on your site. This isn't ideal. Much worse is an unprotected configuration file, this can allow a visitor to learn your database access credentials or potentially even edit them. These two items are very easy to fix; allowing them to stand unsecured demonstrates a fundamental lack of knowledge.
- Cron maintenance tasks. If this isn't under 48 hours, it probably means cron isn't running. This means typical tasks aren't getting run, the biggie here is that database backups. There are many other ways to run backups, but this does mean Drupal isn't backing up itself intelligently. This may be a bad thing even on a dev system (however, we typically disable it on a dev system and have other backup tools in place). On a production system, this means they're not paying attention.
- Drupal core version.
Not really an issue unless your site is live. Typically this isn't an issue, as the vast majority of security issues are mitigated on 99% of Drupal websites for one reason or another. As of this post, there were some recent core security holes that are probably mitigated on only 25% of sites. If your site is in production and your version of Drupal is under 6.28 or 7.19, and you haven't already been informed: this is a pretty bad indicator in 3 out of 4 cases. The other thing to look at here is a really low (old) sub-version number (7.xx or 6.xx); go look up the date of the release of that version and see if that's not the first time they installed Drupal. A lack of awareness of security holes in Drupal core shows a disregard for your security; if they are aware and can explain how the holes are mitigated, this a is a good thing. - Upload progress. If this is not enabled, it's not an issue per se, so it won't be highlighted in red. However, it does generally indicate a lack of familiarity with server technology (again, in production). This allows you to see your upload progress while it's uploading, which is nice. This is a very easy task for a developer familiar with installing server software. I won't go as far as to say the lack of this is a mark against a developer, just one more flag. I will say that it's presence should be a reassurance. If you're on a shared hosting plan, this is actually something your host manages, so disregard this.
- File system. A surprising amount of issues we run into are related to file permissions. This indicator isn't all-encompassing, but it will indicate at least a basic familiarity with file permissions. If this isn't a pass, you probably aren't able to upload files, and Drupal probably can't do it's job to manage the file system.
Footnotes
To reiterate, these are just indicators, and only really helpful if your site is relatively complete or in production. There are more caveats that I can adequately cover here, so don't go firing anyone based solely on this guide, ok? If your Drupal developers fail on multiple of these, I'd recommend discussing it with them, and maybe getting a third party audit.