Drupal 8

Client requirements can be complex and those complex requirements often require custom code to be written. This includes making sure that the editing process conforms to certain validations.

Drupal can easily handle simple validation like having a value in the field or making sure an email is valid, but with more complex validations usually require custom code.

Whilst it is possible to inject custom validators into form submissions, I find using validation constraint classes makes the whole process much more predicable. Also, validation constraints are applied at a lower level than form validations, which means we can validate the data is correct even if we are creating the entity from an API. 

Derivers in Drupal are one of the ways in which you can inform Drupal about the presence of plugin types. This allows you to generate multiple custom types of a plugin so that it can be represented as multiple different plugins within the system.

Perhaps the most useful deriver example I have seen is the menu deriver. This allows us to use the Drupal plugin architecture to generate custom menu links.

If you want to create a menu link for your module then you would normally add them one at a time to a *.links.menu.yml file. This is an example of using the menu links plugin system to inform the menu system about the links you want to add.

PHPStan is a great command line tool for looking at how your PHP code will run without actually running it. It's great for finding potential bugs that you wouldn't have otherwise discovered using other tools or through unit testing.

With regards to Drupal projects there is a little problem in that PHPStan doesn't know how to interpret Drupal plugins, entities, controllers or all the other Drupal architecture that goes into a Drupal module. For this reason, if you try to run PHPStan on your module code you'll find that it produces a lot of errors regarding missing objects or incorrect parameters.

Thankfully, it's possible to easily teach PHPStan about Drupal and make the tool more useful when writing Drupal code. First we need to install it.

Custom Drupal codebases (or any codebases really) can be difficult to maintain. New developers to the system need to familiarise themselves with how the code works and what the system is doing before they can make any contributions.

What makes things more difficult is when a site with lots of custom code has modifications that adapt the functionality to specific users.

I will occasionally come across sites that provide some sort of service, but have made modifications to their code that changes things for a particular user (or set of users). This is often to appease the largest user base on the system that wants things done in a certain way, but the site is unwilling to change things for all users.

Creating a Drupal site can be a complex process. Some people put together Drupal sites using a collection of different modules whilst others use Drupal as a framework and build the site using code.

No matter what sort of Drupal site you have, you'll need to have some testing in place to make sure that it works correctly. This is especially important when applying updates to your sites as the updated code can create unwanted side effects (or contain bugs) that might cause the site to malfunction. Generally, Drupal modules are very good with updates, but there are sometimes interactions between modules can cause problems that weren't taken into account.

When it comes to testing, there are a number of different options available to a Drupal developer. Each of which have their own uses and depend on the type of Drupal site you are trying to test.

In this article, I will go through a number of testing strategies that you can use to test a Drupal site. I won't delve too deep into each topic as this is more of an overview of the different technologies and strategies available.

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.