Drupal 9

Creating services that listen events in Drupal is pretty straightforward; you just need to create and register a service class and let Drupal know what event you want to trigger on.

Altering routes in a Drupal site is also done through an event trigger, but in this case the implementation is slightly different. This is because Drupal takes care of the trigger setup and allows you to create an event subscriber that will automatically trigger when the routes are created.

A while ago I wrote about including oEmbed providers in a Drupal site and briefly touched upon creating custom providers. I didn't go into any more detail there so I decided to write another article looking at creating custom oEmbed providers.

In this article I will cover what oEmbed is and how to set up a custom oEmbed endpoint. I will also then go onto show how to setup and configure a Drupal site to consume that custom oEmbed endpoint. 

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. 

Drupal has a robust and dynamic cache system that allows complex pages to have different parts of it cached in different ways.

Having a cache means that Drupal doesn't need to go back to the database and ask all the elements of the page to re-render everything for every page request. The results of the render can be stored in a cache and served much faster than having to recreate them again.

You might have a page that displays content from a node and contains a few blocks to show menus, search forms, share links, and similar. Each part of this page can be cached in different ways and all of this information bubbles up to the aggregate page cache.

Embedding image within pages of content helps both within the design of the page and when shared on social media. If you set up meta tags to point at a particular image then that image will appear when the page is shared on social media. This makes your page stand out more.

A while ago I added a header image to the articles in the form of a field that references a media item, which is quite typical when adding images to pages. To add an header image to an article I just had to upload an image and Drupal would handle the size, placement and meta data for that image.

With the field in place, however, I spent a while adding a default header image to new articles so I haven't been making good use of it. My GIMP skills aren't that amazing and so the prospect writing an article and spending time fiddling with text elements on an image every week wasn't that appealing.

I have recently been looking at generating custom content entities and this lead to generating a minimal entity that would be useful on a Drupal site.

If you've ever used Drupal Console to generate a content entity, then you'll know what it generates a lot of files. There's all sorts of classes and configuration files generated that handle everything from generating lists of entities and forms for creating new entities.

This got me thinking about what is the minimal amount of configuration needed to generate a usable content entity. This might be used to store some simple data or to attach to other entities through an entity reference. As it happens, setting up a minimal content entity takes just a single file.

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.

The Drupal tempstore.private service is used to allow temporary user data that is available from one web request to the next. It is intended to be used for non-cache data that cannot easily be rebuild. This includes work in progress data that isn't in the position to be saved permanently.

The temporary store is a key value/store and cam therefore store anything from a single value to a serialised object.

The tempstore.private service is really a factory (called PrivateTempStoreFactory) that will allow you to create instance of a PrivateTempStore object. It's this object that van be used to manage the data in the store. If you are familiar with the way that configuration factories work then this will seem familiar.

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.