Drupal

The cache system in Drupal has a number of different components with time, contexts and tags being used to determine the cache.

Whilst all of these mechanisms are really useful you can also inject data directly into the cache system. This is beneficial if you have an expensive function that takes a long time to complete. The result of the function can be stored in the Drupal cache system just like other cache data.

For example, let's say you are pulling data from a slow API. If the data doesn't change much it might be better to add a cache to the request so that instead of going to the slow API the fast cache systems are used instead.

I was recently working on a Drupal form where I needed a user to select from a list of options that were available in a field attached to an entity. As the entity itself didn't exist when the user was filling in the form I needed a way of finding out the options that could be applied to the field. 

Getting a list of values from a field allows for numerous possibilities within Drupal, including configuring modules and creating wizards for generating content. As it took me a little while to track down how to do this I thought a quick post might come in handy for anyone looking to do the same.

In order to get the values available in a field we first need to create a blank entity. This will be used by the field storage system to load the correct field definitions.

Composer is an excellent way of managing dependencies but in order to use it properly it does require a build and deployment process.

The two ways of deploying a site built with composer is to either generate an artefact with the composer dependencies installed, or to install composer as part of the deployment process. Both of these approaches require not committing the vendor directory and other third party libraries (like Drupal core for example) to the git repository.

Many developers tend to go for the approach of committing the composer dependencies to the repository in order to simplify their workflow. This approach, while simple, does have its problems. I have talked about the problems of committing the composer vendor directory in detail in a previous article.

Google PageSpeed tool was created to give webmasters an indiction of how their site will perform when analysed by the Google search engine. As Google takes a variety of different factors into consideration when ranking sites the tool gives an indication of the health of the site.

The score it calculated using a percentage, with different bounds of the score being coloured differently. Between 0 and 49 is poor and is coloured red, between 50 and 89 is average and is coloured orange, above 90 is considered good and is coloured green.

Getting a perfect score in the Google PageSpeed Insights tool is by no means the end goal of site performance improvements or even search engine optimisation. It will absolutely have some benefits in terms of your site traffic though and is worth including in your site key metrics.

This is probably not relevant to some people, but I find that I'm always searching for this information when I need to print out a URL or find the current page path.

The difficulty is that finding or printing out a URL is very contextual and there is more than one way to get or use this information in Drupal. You might have a node object that you need to convert into a fully qualified path, or you want to print out the path of a route, each of which have different approaches. I think that's why there are so many questions asking variations of this topic on sites like Stackoverflow.

What is surprising to me is that there is very little documentation on drupal.org about this. Creating URLs and printing out links is perhaps the most common thing that needs to be done by developers creating themes, outside of changing the classes or markup of a block of HTML.

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.

The Drupal Session Inspector module allows a user to view their current user sessions on a Drupal site. By allowing users to view this information you create a self-service security system where users can see if any unusual activity exists on their account themselves. The module also allows users to delete any sessions they don't like the look of, which protects their account.

This session deletion feature is especially useful in situations where the user has neglected to log out of a computer. They can just log into the site in another location and revoke that session, securing their account from accidental access.

As part of my continuing work on the Session Inspector module, I wanted to add an events system that could react to this deletion of sessions.

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.