Drupal 8

Pushing data from Drupal into Solr is a really convenient way of creating a robust and extensible search solution. The Search API module has a number of different fields available that can be used to integrate with all sorts of fields, but what isn't included is computed fields or other data.

Thankfully, adding a custom field into the Search API system doesn't need a lot of code. A single class, with an optional hook, is all that's needed to het everything working.

I was recently looking at the node view count module that was being used to record what users viewed what nodes on a Drupal site. What was needed was a report page that had a bunch of data from different fields of a node, along with the node view count data. As this data wasn't immediately available to Solr I needed to find a way to inject the data into Solr using the mechanisms that Search API has. 

You've probably been there before. A Drupal View you are working on looks great and has all the data and fields you need, but when you look a little closer at the results you realise that something is off. After looking at the generated SQL query you see that there is a problem with one of the joins which causes your counts to be off a little. Ultimately, you need to remove this join, but you really need that data included in your results.

Creating a subquery can allow you to pull out data from a specific field without adding another join that would cause the results to be out.

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 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.

Tailwind CSS?

In case you haven't heard of Tailwind CSS I'll quote the site here.

"Tailwind CSS is a highly customizable, low-level CSS framework that gives you all of the building blocks you need to build bespoke designs without any annoying opinionated styles you have to fight to override."

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: