Drupal

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. 

Drupal's login forms are protected by a protection mechanism that prevents brute force attacks. This means that if an attacker attempts to repeatedly guess a user's password to gain entry to their account they will be blocked before being successful. This system has been a part of Drupal for many years and so is battle tested.

Like all systems in Drupal, the flood system can be adapted to be used on your own forms. Which means you can protect any form that you don't want to be used too much. This will help with authentication forms or any form that might need to process lots of information where you don't want users to submit the form too much.

Before using the flood system on a form you first need to inject it into the form. Here is a basic form setup with the flood service injected into it.

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.

Whilst Twig is a powerful tool in its own right there are occasions when you need to pull out data from Drupal or manipulate it in certain ways. I normally do this using preprocess steps, but I recently found that it was also possible to extend Twig within the Drupal framework to provide your own functions and filters. This can be useful if you have custom templates and need to perform special actions on data items to format them in different ways.

Setting Up

Before we can create Twig filters and functions in Drupal we need to tell Drupal that we have a class that contains them. This is done by creating an entry in the your module services file that contains the tag tag.extension. In a module called "custom_twig" the file would be called custom_twig.services.yml and would contain the following.

I've been using composer with Drupal for a few years now and I've picked up a few things along the way that have really helped me out. Following on from my post about the anatomy of the recommended Drupal 9 composer file I thought it would be good to expand on that to present some tips.

Here are 7 tips that will help you out when using composer with Drupal.

Automatic Patches With Composer

One of the most useful things I have found is using composer to manage patches to projects. This is possible using a project called composer-patches. You can require this into your project like this.

According to the official Drupal documentation, to create a new site using composer you should use a composer template project called drupal/recommended-project. This has a default composer.json file setup with some values that will help you get up and running swiftly with a new Drupal project.

It's a good initiative to get you up and running with a standard Drupal site pretty quickly. I've used this composer project a number of times now, but I haven't really looked at what's in it. I thought I would dive in and see exactly that's in there and dissect it line by line.

To reiterate what's in the Drupal documentation, to create a brand new Drupal project using composer use the following command.

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.