Drupal 8

I was recently working with a Drupal 9 site and found some strange behaviour when saving certain types of content. The page would appear to save, but much of the content appeared to be missing. It had even failed to generate the paths for the page based on the path auto rules.

Digging deeper I found the root cause of the problem was an improperly created redirect in an insert hook within custom code written on the site. This code looked for the creation of a particular content type and then forced the redirect to happen.

The lazy builder API in Drupal allows the creation of highly dynamic content within a render array without having to disable the cache for the entire render array or the page the content is attached to. What this means in real terms is that the initial render array can be cached quite heavily, but lazy builders allows for additional rendering to be done in after the initial rendering pass to generate content.

There are several reasons why lazy builders might be useful. The most useful reasons are to present some highly personalised or dynamic content to a user, but you might also want to offset the rendering of some slow code to give it some more fine grained caching that stores the outcome in a cache bucket.

Lazy builders work by using a normal render array, but instead of rendering the content you inject a lazy builder placeholder into the content. A callback method is used to tell Drupal how to inject the content into the placeholder.

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.

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.

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.

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.