So 2020 is in full swing, we are already midway through February and any new year’s resolutions you may have set yourself may have slipped … but why not set yourself a new resolution of keeping on top of your Drupal site maintenance? Even as a developer working with Drupal every day, sometimes you can forget some of the basics in regards to site maintenance, so I’ve detailed some of the most important aspects you should be mindful of below.
Core & Contrib updates
Without a doubt, one of the most important things (if not the single most important thing) you can do for your Drupal site security is keeping the site up to date with the latest Drupal Core and Contrib module security updates.
Drupal has a security release window of every Wednesday for Contrib modules and one Wednesday a month (usually the third of the month) for Core updates. It’s important to be aware of the Wednesday release window as more often than not multiple security updates for Contrib modules can be released at the same time, so you might have quite a few updates to apply to your site. For further information on the release window timing, read this article from Drupal.org.
Rather than checking manually, you can subscribe to the security update mailing list through your Drupal.org user account profile so you’ll get notified as soon as the updates are released. At ComputerMinds we have taken this notification process one step further by having tickets raised in our support system automatically based on which modules a site has that need updating.
We created a little module that we have on all our clients’ sites, which notifies our issue tracking system which modules the site has enabled. We also have Zapier setup to pull in the updates from the security mail listing, and then tickets are created in our issue tracking system for each site that runs the module in question, so we never miss an update. Neat, eh?
User account audit / Permissions
In addition to security updates for modules and Drupal core, as a site administrator you may want to conduct a user account audit on your site. This could include running through a list of all the user accounts on the site that have administrative privileges, and double checking that all the accounts are still needed, and that there aren’t any users with an elevated administrative role that shouldn’t have one.
In addition to this, you may wish to conduct a review of permissions that each user role has on your site. Check the permissions administration page to see each role and it’s permissions – you’ll want to make sure that no user role has a permission that it shouldn’t have (be especially careful to check the Anonymous role, you don’t want any anonymous user to the site to be able do anything with administration!). Sometimes when a site has quite a few user roles in place and a lot of permissions from contributed modules, the permissions admin page can become hard to read with all roles and permissions displayed on the same page. In this instance it’s usually easier to load up the permissions page for each user role individually and check the permissions that way.
I’ve briefly touched on some key points on how to boost site performance in a previous article but it is always an important topic to ensure your Drupal site is running smoothly as possible. You’ll want your pages to be served up to people quickly to ensure they have the best possible experience whilst using the site.
Server PHP Version
Checking what PHP version the web server is running your Drupal site from is important as you may be running an older (probably now unsupported!) version. Upgrading the version of PHP to a newer one is a great way of bringing speed improvements to your site. PHP > 7.0 provides great speed improvements over PHP 5.x and the newest supported version (currently 7.3.x) provides even more performance gains! When Drupal 7 was released it came with support for PHP 5.3.x but as of 1st December 2019, the minimum recommended version for your Drupal 7 site is now 7.2.x.
This is because PHP versions prior to 7.2.x are now past EOL (End of Life) so upgrading the version of PHP on your server should be a top priority. Drupal 8 was released back in November 2015 (has it really been that long!?) with PHP 5.5.x support but now that version is not supported at all. At a minimum PHP 7.0.8 could be used but PHP 7.2.x is now the recommended version for any Drupal 8 site. If you can upgrade to PHP 7.3.x though, this will currently provide the best performance improvements.
Of course, you can’t just upgrade the version of PHP and assume your site will continue to work as it was. You should ensure your Drupal Core version is up to date and you will have to check all the contributed modules that you have enabled on your site for compatibility . Chances are, if you have been running an outdated version of a module, it may be using deprecated or even removed functions that the newer versions of PHP don’t support.
If a module appears like it’s causing trouble with a newer PHP version, you’ll have to check if there is an update available for the module. Most popular contributed modules should have been updated already to support the recommended minimum PHP versions by Drupal. Apply the update in your development / test environment first, and test it thoroughly. If the module doesn’t have an update available or still isn’t working quite correctly, there might be an open issue on the module’s page on Drupal.org with a patch ready that just hasn’t been committed yet. If that isn’t there, then you may need to to write a patch for the module in question to support the newer PHP version. Feel free to get in touch with us at ComputerMinds if you have any modules that need patches written to support newer PHP versions.
A bit of Housekeeping
Status report page
An easy way to find out if there are any issues with your Drupal site installation is to check the status report page – /admin/reports/status. This page will give you an overview of your site’s parameters and show any problems that Drupal has detected with your installation. Problems may include: your Drupal Core version being out of date and insecure; file system permissions problems; insufficient PHP memory limit; cron not configured properly and a range of other things.
You should have a good read through of the messages on the status report page and action any errors as soon as possible. The warnings displayed here may or may not be an issue for your particular installation (depending on the warning message) so you’ll need to see if they are actually an issue for your site or not.
Module tidy up
As your Drupal site grows over time with more functionality, chances are the site will have quite a large amount of contributed modules enabled. It may be worth checking that you actually do still need all of them enabled, as requirements do change over time and you may have some modules left enabled that you don’t actually need any more. Every extra module that is enabled that doesn’t need to be has the potential to slow your site down, so be sure to have a thorough review of the module list and see if you can get away with disabling any that aren’t used anymore.
Content type tidy up
If your site is a number of years old, chances are it may also have some content types that were used at some point in time but may no longer be used or needed. If you are 100% sure that you can get away with deleting a content type because you don’t have any nodes in place that are built using it and no other functionality relies upon it, then you can delete it from the system. Any fields that were used exclusively by this content type will also be deleted from the database. However, before doing any permanent action such as this it would be a sensible idea to backup your site database first, check that your backup works and that you can actually restore the backup if need be.
On a Drupal 7 site, you are probably using the Features module to manage configuration and to keep configuration consistent between environments. Over time additional changes may have been made directly on the live site environment without being exported back into code. If it’s not enabled already, the Diff module enables you to easily see what changes there have been in your features between the active configuration on the site and the exported configuration in code. If there are any changes that have been made on the live environment that should be kept, be sure to download the changed feature(s) from live and update the codebase with the changes.
On a Drupal 8 site, you’ll probably be using the lovely built in Drupal 8 configuration management in order to manage your configuration along with Configuration Split to have environment specific configuration in place. Again, the same principle applies here that your live site environment may have configuration changes that you may want to export to your codebase to maintain consistency.
For more information about importing configuration in Drupal 8 without losing changes, check out this excellent article by our very own James Williams.
Photo by Kateryna Babaieva