Drupal

A recent challenge that I faced on a project was to generate the HTML of a full Drupal page, from within a Drupal request. The project called for a template to be rendered within the structure of a Drupal theme and also to include the styles associated with that theme.

At first, this doesn't seem like a big problem, but once I started trying to figure things out it became much more complex than I was expecting.

The problem is that you can't just render a page using the 'html' and 'page' templates as there is a lot of context surrounding those templates. Without this context in place Drupal produces a page of markup that contains no styles or blocks. The context is how Drupal knows what theme to load, what libraries to add to the page, what preprocess hooks to call, what menu items to generate, and so on.

I have written lots of detail about using update hooks to manage updates in Drupal and they have all been about the hook_update_N() hook. The hook_update_N() hook is just one of the options available in running updates as the update pipeline also includes hook_post_update_NAME(). The hook_deploy_NAME() hook, bundled with Drush 10, can also be used as an update hook in the same way.

Each of these update hooks has a number of different best practices when considering their use. All of these hooks are run once and once only and the key idea is that they take Drupal (or a module) from one version to another by adding database changes or configuration updates as the module gets updated.

For example, if you have a module that has a database table then it will be stored as schema information within your module. Once you release the module you must ensure that everyone who already has the module installed can still use it after the schema has changed. This means that as well as updating the schema information you also need to provide steps in the update hooks to update existing installs. Without this step the module would likely crash as it attempts to inject data into tables or fields that don't exist.

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.

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.