Drupal 8

I recently needed to add functionality to the Password Policy module so I thought I would outline the steps I took in a blog post. The Password Policy module is used to enforce a stricter password policy on users on a Drupal site. This means that when a user creates or changes their password they must conform to certain rules like the password length, or if it contains upper and lower case characters. There are a set of rules to chose from and they can be fully customised by the site administrators. It's a good module, you should check it out.

One gotcha when importing configuration to a Drupal site can be a message that tells you that the configuration you are trying to import is from another site.

Here is the error that can be seen on the Configuration Synchronize page.

The staged configuration cannot be imported, because it originates from a different site than this site. You can only synchronize configuration between cloned instances of this site.

This error happens because the UUID of the site (in the database) is different to that in the configuration (in the code). The UUID in the code is stored in the configuration file system.site.yml. The reason for this check is to ensure that your don't destroy your Drupal site by installing configuration that was created from another site.

Installing a Drupal site from configuration is useful when running tests or if you don't have a copy of the database. You'll get a copy of the Drupal site without any content that will act in the same way as the live site. You can use modules like default content to add content into the mix so your newly installed site acts a little bit more like the live version.

Since there are some prerequisites to get this up and running I thought I would run through what is needed to get this working and how to run it.

A change that was snuck into Drupal version 8.8.0 and wasn't mentioned in the 8.8.0 change notes was a small change to the setting that controls the placement of the configuration directories. The alteration deprecated the $config_directories setting from the settings.php file and move the configuration into the $settings array. You can see the detail behind this change on the Drupal change record.

The fix for this is very easy and only needs a single line of code to change in your settings file.

Change this:

$config_directories['sync'] = '../config/sync';

To this:

Spam is a constant problem for any site on the internet that has a publicly available form, but automatically preventing spam can be tricky. The idea is to prevent the automated spam bot from being able to submit data to your site, but not at the detriment of the users. There is a careful balance between preventing spam and prevent real content being submitted by real users. Manually moderating blog comments is usually a good idea, but many websites contain contact forms and user registration forms that are often targeted by spam bots.

Whilst Drupal does have a number of protections against cross site submissions or denial of service attacks and even has build in user and comment moderation. It does, however, need a little bit of help with preventing spam.

Drupal has a number of modules to deal with automated spam and they fall mainly into a number of different categories.

Drupal 9 will be released on June 3rd, 2020 so with this just around the corner I thought I'd put together a post about how to check if your site is ready. The transition from Drupal 7 to Drupal 8 was more of an upheaval than an upgrade. Updating a Drupal 7 site to Drupal 8 requires a lot of effort involving code changes and migration steps. Drupal 7 modules are not compatible with Drupal 8 and so any custom code written needs to be adapted to the new structure of Drupal. The difficulty of this change made the Drupal community take notice and think about how future versions of Drupal are introduced.

Drupal Views is a great way of exposing data to users via a search interface. This can be done directly via the database or via a Solr server. Plenty of Views plugins exist to allow reacting to the search input and output in a variety of different ways.

The other day I needed to add a personalised message to Views output to inform a user that their search keyword didn't find any results. There is a plugin for Views that allows this, but it only shows a basic search string.

What I needed was a way to print out the following block of HTML, containing the search term that the user searched for.

Upon a recommendation from someone in my local Drupal user group I decided to give Tailwind CSS a go. The ultimate aim of this was to replace the base theme I am using here with a more stripped down theme. At the time of writing this I am using the Cog theme, and whilst it has it's merits, I find that it's a little too much for this simple site.

I decided, therefore, to create a new theme and use Tailwind CSS to alter the site a little. This meant an exercise in integrating Tailwind CSS into a Drupal theme.

Whilst searching for an answer to a problem the other day I found a comment that details a command that prints out all of the FieldWidgets available in Drupal 8. This is useful if you are looking for all of the field widget classes in Drupal8.

Here is the command:

grep -rl '\@FieldWidget' | xargs grep -m1 'id = ' | grep -o FieldWidget.*

This prints out something similar to the following:

I perform a lot of Drupal updates, and they mostly go very well. The code updates without incident and the database updates apply whatever updates they need without a hitch. Every now and then, however, I will come across a project that hasn't received updates in a while, which means there are a lot of database updates to run through.

Having Drupal run 100+ database updates across modules and core can be a bit problematic. Some modules will require core updates to happen first, and when this happens out of order the database update update fails spectacularly.