I'll put this here, in case it helps anyone else.
I'm owning up to Drupal Schoolboy Error #1.
I was writing a very simple module. It did so little, that I wanted to keep things as simple as possible — just a .info file, and a .module file.
OK - I'll hold my hands up. The title of this post is misleading. I'm not going to give you an ABC on how to secure a Drupal site (maybe another day). I'm responding to a post on the Reseller Club blog entitled How to Secure Your Client's Drupal Website.
There is some good advice in that article, but it's mixed in with some bad advice, and in other parts it's just plain confused. In the hope that it helps people, I'm going to try and untangle things.
The Drupal Security team has just released a public security announcement, PSA 2016-001.
There will be multiple releases of Drupal contributed modules on Wednesday July 13th 2016 16:00 UTC that will fix highly critical remote code execution vulnerabilities (risk scores up to 22/25).
If you run any Drupal sites, please be prepared, and be ready to update your site as soon as this is released.
Drupal 7 and below came with an optional module you can use in your input formats - the "PHP Filter". This allows you to put PHP code into the content of your webpages, and Drupal will process the PHP before rendering the page.
Last week, to appropriate fanfares, Drupal 8 reached Release Candidate stage. That means Drupal 8 tagged releases now have an upgrade path between them, and it also means (very nearly) complete API / hook stability - which means this is the cue for some serious testing and development of contrib themes and modules.
However I made one schoolboy error: I was still using Drush 7.
It's actually quite an understandable mistake - all you had to do was follow the development of Drupal Next, and Drush, but not quite follow it closely enough.
In case you missed it, Drush has evolved recently.
Quick primer for beginners follows. (Although, if you haven't heard of Drush, the chances are this post was not written with you in mind. I blog about many subjects, and there aren't many readers who are interested in all of them!)
Drush stands for Drupal shell - it's a very powerful shell environment for managing Drupal sites using the command-line shell.
Yesterday, Drupal 7.28 was released.
People rush to upgrade, knowing that there will be a tranche of bug-fixes that may resolve longstanding issues.
People hesitate to upgrade, because updating Drupal core is not as simple as we'd like.
Other times, the core update is a security release, and you can't afford to wait.
This does not need to be painful!!
Upgrading core in Drupal 7
You have probably read the official documentation on doing this.
Earlier this week, I got several automated e-mails from Drupal sites I manage. The e-mails told me that some of the modules I use had a new version, so I was advised to log in and upgrade.
I was puzzled to see that one of the modules I maintain was in the list of pending upgrades. That was puzzling because I hadn't pushed any changes to that module for a little while, so I wasn't expecting any new releases.
Yesterday, the PHP group announced the first stable release of PHP 5.5. This is great news. I shall compile it very shortly so that it can optionally be used on this server. That will allow me to test my various Drupal sites against PHP 5.5, to see if there are any issues.
However the arrival of PHP 5.5 signals the imminent end of PHP 5.3. Back in December 2012, PHP announced that