Drupal 8 and 9 are built upon services, with many parts of the system available through dependency injection, so it's important to understand the concepts. Services are a way to wrap objects and use dependency injection to produce a common interface. They are powerful and are used all over Drupal to do pretty much everything.

They can, however, be a little difficult for newcomers to the system to understand, especially if they are coming from Drupal 7 or other non-object oriented systems. When you look at some Drupal source code you are likely to see objects being created out of apparent thin air. It's a little hard to know where they come from if you aren't used to the how they work.

PHP has a built in debugging and testing tool called assertions, which is essentially the assert() function and a few configuration options.

With this feature you can add additional checks to your application whilst you are developing it so that when you deploy to production you can be sure that things will run correctly. It is simple to run and allows you to embed testing code within your production code without having an adverse effect on performance.

I've seen the use of assert() in a couple of open source PHP projects, but had not really dug into how it works or what it does. As it turns out, assert() is actually very useful and can also be found in other languages like C/C++, Python and JavaScript.

Naming things is hard^{[citation needed]} and there are a lot of things that you can name when configuring a Drupal site. Picking the right machine names for the different parts of Drupal can make your life easy in the long run. Changing labels is simply a case of tweaking the label in the interface, or through configuration updates. The issue is that once you decide on a machine name for something in Drupal it's pretty much set in stone forever.

The machine names you pick are often used in database tables, paths, interface elements and pretty much anywhere it is used. Changing entity or field machine names at a later date is difficult and can mean writing complex code or using migrations to achieve.

I have previously talked about configuring a Drupal site to authenticate against a remote SimpleSAMLphp install, but as Drupal is an excellent user management system I wanted to turn it around and use Drupal as the identity provider. This means that Drupal would allow users to log into other systems using their Drupal username and password by leveraging the power of SimpleSAMLphp.

This can be accomplished by wrapping the Drupal site and SimpleSAMLphp together along with a couple of modules to power the communication between the two systems.

The same terms apply as I described in the previous post, but to reiterate their meaning in this context I will go over them again.

I have previously talked about installing SimpleSAMLphp using composer, so the next step is setting up the system to actually provide authentication against a SimpleSAMLphp system. As I spend a lot of time using Drupal I wanted to set up the authentication with Drupal and SimpleSAMLphp in order to see how things worked.

First, let's define a couple of terms that are important to this setup.

SP - Service Provider - This is the system that users are trying to log into, which in this setup is Drupal. The Drupal site is providing a 'service' and as such users want to authenticate with it. Service providers will generally create a local user to track the user within the site, although that's not always the case.

Security Assertion Markup Language (SAML) is a standard that passes authentication credentials between hosts and essentially allows for a single sign on solution to be created. The standard uses XML files that get passed between the authentication system (known as the identity provider or IdP) and the service users want to sign into (known as the service provider or SP). 

SimpleSAMLphp is an open source application that implements SAML mechanisms and allows for the authentication system to be created as well as some administration tasks to be performed. The system is robust and battle tested, having been integral to the open source authentication systems for a number of years.

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.

I recently acquired a Vissles V84 mechanical keyboard and I have spent some time giving it a go. Vissles was founded in 2018 and have a selection of decent looking accessories and devices including wireless chargers, headphones and monitors. The V84 is the second of keyboard that Vissles have created, iterating on the previous design.

The keyboard itself has 84 keys and is a 75% ANSI layout, this is also called tenkeyless as it is a normal keyboard without the keypad. This keyboard moves a few of the keys around in order to fill the entire surface of the board with keys, rather than separate out the arrow and home/end keys. The compact design gives the keyboard a slim look, but it doesn't feel cramped or small to use.