Drupal sites contain a settings.php file with site-specific settings, that is based off default.settings.php at the time the site is installed. As Drupal evolves, default.settings.php will change. Sometimes, it's worth incorporating those changes into the settings.php file for an already-installed site. This post runs through a low-friction way to keep on top of this house-keeping.
cPanel offers users a shared hosting environment which could be thought to exclude running NodeJS (and therefore Node driven theming tools like Gulp and Grunt). In fact, this is easily overcome, as I explain here.
I've been putting off learning how to build sites in Drupal 8, and migrating my existing Drupal 7 sites over to Drupal 8. Why? Drupal 8 uses a lot of new tools. I want to learn how to set up a Drupal 8 site in the "right" (optimal) way so that I don't incur technical debt for myself later on. That means I have a lot of tools to learn. That takes time, which I don't have a lot of. So I've procrastinated.
I'm a big fan of Piwik, an open source analytics suite. Think Google Analytics, StatCounter, Sitemeter, etc. … only self-hosted an open source. There are many benefits of using it:
Drupal 8 and 9 use Composer for package management, but Composer requires more memory than is available on most shared hosting environments. This post discusses the problem, and explores a way of working around it to get things working.
Yesterday, at 7.13pm, the Drupal Security Team issued a public service announcement: Drupal 7 and 8 core highly critical release on March 28th, 2018 PSA-2018-001.
This needs a bit of background to understand.
How Drupal Core Updates Normally Work
Updates to Drupal Core fall into one of new kinds.
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.