Drupal

The events system in Drupal 9 allows for different parts of the system to communicate in an object-oriented manner. During the normal processing of a page, Drupal will trigger events that components will subscribe to in order to perform actions. The events system is built upon the Symfony event dispatcher component, which is an implementation of the mediator design pattern.

The mediator design pattern is a way for objects to communicate with each other through a mediator object (hence the name). The idea being that the different parts of the events system are never directly linked. This reduces the dependencies that objects have and allows parts of the application to be decoupled. Events are useful in a large and modular application like Drupal as it allows different parts of the application to work together without having to explicitly reference the objects involved.

I've been building Drupal forms for a number of years so I'm quite familiar with to putting together a Drupal form using the FormBase class and the form API. When I attempted to create a GET form this week I realised that there is actually quite a bit to think about. All forms are built using GET requests, it's the submission that I am specifically talking about. By default, forms in Drupal use POST requests to submit their data, and although it is possible to convert a form to use GET to submit data, it isn't well documented.

There are a couple of GET forms already available in Drupal. If you look at the Views filter form or the Search form they both process submissions through a GET request. These forms tend to use a combination of a form, a hook and a controller to manage their rendering and results. What I wanted was an example of a GET form that was more self contained inside a Drupal form object.

If you run a Drupal site for any length of time you will quickly realise that a few paths that have nothing to do with Drupal will receive a lot of traffic. All of these paths result in page not found errors so the only impact is taking up your server resources. It's common to see paths like wp-login, xmlrpc.php, phpBB/page_header.php, postnuke/article.php, as well as a multitude of others. These requests are clearly bots probing the site to see what sort of CMS is in use and if they can exploit it or not.

It's a bit of a shame that the internet is like this, but it's just one of the things you need to be aware of when managing a website. Users, and more often, bots, will continuously probe your site and servers for exploits. This is why you need to have firewalls and ensure your software is up to date as people are only too willing to crack your site and expose your data.

Drupal configuration is normally changed or removed through the configuration import and export process. For example, the process I follow is to make the change in the configuration locally, export the configuration into the source code, deploy the source code to a remote server and import the configuration. Using this mechanism, configuration changes that were exported locally are imported into the site and are ready to use.

There are certain situations where using update hooks to update the configuration is necessary. This means that you would change the configuration in your system directly using code in update hooks, rather than following the export and import process. These situations are rare, but necessary from time to time in order to maintain a consistent configuration on your site.

Drupal Views is a powerful module. The ability to generate lists of things in Drupal means that it is used everywhere. It even has a powerful plugin system that allows other modules to interface with it and create more functionality.

With multilingual sites there is a common issue I come across quite a lot that is quite easy to fix. A View will be created (usually via the Views wizard) that is intended to list a type of content. When an item of content is translated the content is duplicated in the View and you end up with a single list containing both translations of a single content item.

A robots.txt file tells search engines spiders what pages or files they should or shouldn't request from your site. It is more of a way of preventing your site from being overloaded by requests rather than a secure mechanism to prevent access. It really shouldn't be used as a way of preventing access to your site, and the chances are that some search engine spiders will access the site anyway. If you do need to prevent access then think about using noindex directives within the page itself, or even password protecting the page.

Getting a list of content types out of a Drupal 9 site is useful in a few situations. Mostly, I find that when creating a service of some kind that I will also create an administration form for that service to allow it to be restricted to certain content types. This list can be saved to configuration so that when the service is run it only effects certain content types, based on the saved configuration.

To get a an array containing a list of the content types on a Drupal site you can use the following code.

Normally, when creating Tweets from Drupal 8 I use the Social Post Twitter module. This module is part of the Drupal Social Initiative and has been my go-to module when I've needed to read or send Tweets from a Drupal site. Since the release of Drupal 9, however, these modules have not been receiving the support needed and as of writing this article there is no easy way to install them on a Drupal 9 site. I've looked into the issue queues and can't see why the delay is there.

The Social Post Twitter module does have a lot of features that I didn't need for what I was looking for, which was to send Tweets when items of content are created. I decided to see how difficult it would be to send Tweets from a Drupal site as an item of content is published.

I was writing some code on a Drupal site that detects if a page is being published and I realised that this state isn't as clear cut as you might expect.  Drupal stores the published state of a page as the 'status', with 0 being unpublished and 1 being published. With revisions being turned on by default since Drupal 8 it is possible to see past states of the page when saving the page. The issue is that there is nothing in the current state of the page stating that this is the first time it is being published.

As an example of this in action, and where I cam across this, we can use the hook_ENTITY_TYPE_update() hooks to detect if a page is published as it gets updated like this.

Drupal's update hook system is a powerful way of updating your site to introduce things that wouldn't be handled using the configuration system.

Modules will use update hooks to bring sites that have the old version of the module in line with the latest additions to the module. For example, if a new field is added to a table that the module uses then an update hook will be needed to add that field to all sites that are current using the old version. This update hook will be in addition to the install hook that would install the table with the added field in the first place.

There are a number of different reasons why you would want to use update hooks on your own site. Normally being stored in either install profiles or custom modules they would be run on deployment in order to update your dev/stage/production site with changes without having to manually apply them. This is a useful way to do one of the following actions.