Drupal

Drupal 9 gives you a lot of flexibility to place node fields into different areas of the site, but there are some limitations. You could use the field display manager to change the order and format of the fields, or install the layout builder module and organise fields into sections.

The problem comes when you need to display some fields outside of the limits of the node template. For example, you might want to show a header image within the page template, or print a curated list of links in the sidebar. These situations exist outside of the node template so you need a different way of adding those fields to those parts of the page.

There are just some situations where you just need to render out a field to a different part of the page.

Since starting the Session Inspector module I have been busy adding features to improve how the module functions.

One of these additions is the module now being able to retrieve and store the browser that the user is current using to access the session (also known as user agent string). This just uses a hook_user_login() hook and stores the browser using the standard session storage system built into Drupal. This browser string is then pulled out of the session metadata and presented to the user in the session inspector interface.

Whilst this provides the user with more information, the one big downside is that when accessing the session inspector page the user sees a browser string that looks something like this.

Mozilla/5.0 (Macintosh; Intel Mac OS X 12_2_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.109 Safari/537.36

I recently had this idea for a new Drupal module that allows users to manage their sessions. The idea is that a user could look at their current sessions to see if any suspicious activity had happened on their Drupal account. They could then delete any sessions they don't like the look of in order to kill off that session.

The functionality I describe here is actually quite important as it allows users the ability to spot suspicious activity on their accounts. I have even used it in the past when one of my accounts was hacked. The fact that the session was opened from Brazil helped me inform the site that something was wrong.

I did some searching on Drupal for a module that did the same but didn't find anything so I thought I would create a module and go through the process of creation in an article. This includes the research into how this can be achieved in Drupal, looking at designing the interface, and then adding code to create the needed effect.

Drupal 9.3.0 came with a new feature called entity bundle classes. This allows more control of entity bundles within Drupal and provides a number of benefits over the previous mechanism of using hooks to control everything.

Drupal makes extensive use of entities to manage content and configuration. User details, pages of content and taxonomy terms just a few of the things that are represented in a Drupal site as content entities. Different types of similar configuration are called configuration entities, which would include things like text format settings or even date formats.

Content entities are normally fieldable, and in the case of content types and taxonomy terms Drupal allows users to generate their own variants. These different variants of entities are called bundles. Entities define the types of objects found in a Drupal site, bundles represent the different sub-types of these entities.

Drupal has had the ability to use oEmbed in core since version 8.6.0. It was included along with the other media changes that went into core in that version. 

I have used some of the Drupal core oEmbed functionality to include YouTube videos into content, but I've never dug deeper to see what else I could do with it. Although Drupal comes with Vimeo and YouTube services available there are many more services to include, you just need to enable them.

In this article I will show what oEmbed is, how to use it out of the box, and then how to add more services to your system.

I'm not a fan of the summary option on body fields in Drupal. I've never really got on with how users interact with it or the content is produces.

The field type I'm talking about is called "Text (formatted, long, with summary)" and it appears as an add-on summary field to a normal content editor area. It comes as standard on Drupal installs and appears on all body fields. The field type has it's uses, but I often find that the content it produces is unpredictable and doesn't have a great editing experience. I have even written articles in the past about swapping the summary field to a fully fledged wysiwyg area for Drupal 7, which worked on the project I implemented it on.

Let's look at the body summary field in Drupal and see why I have a few problems with it.

When creating Drupal modules I like to keep the hard coded components to a minimum. This helps when changing parts of the module in the future as hard coded links and other elements will require manual intervention and slow down maintenance. Sometimes, though, this isn't an option as you just need to have a few routes in your *.routing.yml file that point to controllers or forms within your module.

I had a situation today where I was looking to load all of the routes that are contained in a module. I could then construct a page of links that would handily point to different parts of the module or feed those links into a sitemap. This meant that I wouldn't need to hard code this list into a controller, I just needed to load all the routes and print that list out instead. Especially handy if I ever added or removed a route as that would mean that list would update without me having to do it manually.

If you've been building websites sites for a while you will realise that no site lives in isolation. Almost every site you build integrates with some form of API, and this is especially the case for the more enterprise sites where data is often synchronised back to a CRM system or similar. Drupal's hook and service architecture means that you can easily build integration points to that API to pull in data.

Pulling in data from an API into a Drupal site means installing an off the shelf module or creating a custom module to provide the integration. What route you go for depends on the integration, but for enterprise sites the API is quite often very custom to the business. I have even seen APIs being built at the same time as the site that it needs to integrate with, which is especially the case for startups and new businesses.

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.

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.