Drupal 9

A recent Wired article about the Parler data hack talked about how a hacker group was able to steal publicly available information from the Parler website using an Insecure Direct Object Reference (IDOR) or enumeration attack. This type of attack involves a hacker looking at the structure of the site and attempting to guess the next available resource by looking at the URL. Apparently, terabytes of Parler's data was downloaded by simply enumerating through the ID's of their publicly available posts.

I tried to do something the other day that I thought would be quite simple, but turned out to be really hard to get my head around. I had a Drupal 9 site with Paragraphs installed and I wanted a user to click a button on the node edit form and inject a particular Paragraph into a Paragraph field.

I found 2 solutions to this problem that solve it in slight different ways.

Piggy Back On Existing Events

After my initial struggles over trying to get this to work I decided to use a piggy back method. This essentially listens for the user interaction and then triggers the Paragraph add event that inserts the Paragraph into the field. The user interaction I was listening for was a user selecting different elements in a select list.

To get this working I added some JavaScript to the page, attached to the select list field called "field_type".

For the last few years I have been tagging articles as I write them on this site. This tagging has largely been to tie posts together in an aggregated list of other posts tagged with that term. I recently wondered if I could use those tags to show related content below each article. I have struggled with this feature on client websites in the past and it either boils down to a manually curated list or some sort of complex content analysis and Solr search.

As it happens this is fairly easy to accomplish using Views, although took some working out to get the effect I wanted. I'm writing down these instructions to help me remember how I did it in the past and to allow you set up the same thing (if you wish).

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.

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 like working with DrupalVM and I've worked with Ansible based Vagrant setups for years and so I'm very familiar with it's setup. More than that, I find I have very few problems with running it. I normally run it with Vagrant, but you can run it with Docker if you like.

When starting a new site project I normally add DrupalVM to the codebase so that I can get the site up and running quickly. This is especially useful if something like Solr is involved as setting that up is a pain. I thought I would go through the steps involved in adding DrupalVM to your codebase as it's pretty simple and will get you up and running with a Drupal site in about 10 minutes.

Start out with a Drupal site in a composer setup. I normally run the Drupal recommended composer setup file so that I have a up to date Drupal codebase, so let's do that here.

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.