Drupal 9

This is the third article in a series of articles about the Batch API in Drupal. The Batch API is a system in Drupal that allows data to be processed in small chunks in order to prevent timeout errors or memory problems.

So far in this series we have looked at creating a batch process using a form and then creating a batch class so that batches can be run through Drush. Both of these examples used the Batch API to run a set number of items through a set number of process function callbacks. When setting up the batch run we created a list of items that we wanted to process and then split this list up into chunks, each chunk being sent to a batch process callback.

There is another way to set up the Batch API that will run the same number of operations without defining how many times we want to run them first. This is possible by using the "finished" setting in the batch context.

Drupal has a quick and convenient way of creating ajax dialogs that gives users the ability to embed links in content that open up dialog boxes when clicked. This is a useful way of presenting a bit of content to a user without them navigating away from the page.

I have previously written in detail about creating ajax dialogs in Drupal, and I refer back to that article quite often when the need arises.

The simplest way of creating an ajax dialog is by adding the class "use-ajax" and the data-dialog-type attribute, which can be one of dialog, dialog.off_canvas, dialog.off_canvas_top and modal. Using the "use-ajax" class tells Drupal that this is an ajax link and to intercept the click to perform an ajax request.

Routes in Drupal can be altered as they are created, or even changed on the fly as the page request is being processed.

In addition to a routing system, Drupal has a path alias system where internal routes like "/node/123" can be given SEO friendly paths like "/about-us". When the user visits the site at "/about-us" the path will be internally re-written to allow Drupal to serve the correct page. Modules like Pathauto will automatically generate the SEO friendly paths using information from the item of content; without the user having to remember to enter it themselves.

There are a number of different tools that allow you to validate and test a Drupal site. Inspecting your custom code allows you to adhere to coding standards and ensure that you stamp our common coding problems. Adding tests allows you to make certain that the functionality of your Drupal site works correctly.

If you have tests in your Drupal project then you ideally need to be running them at some point in your development workflow. Getting GitHub to run the tests when you push code or create a pull request means that you can have peace of mind that your test suite is being run at some point in workflow. You also want to allow your tests to be run locally with ease, without having to remember lots of command line arguments.

In this article I will show how to set up validation and tests against a Drupal site and how to get GitHub to run these steps when you create a pull request. This assumes you have a Drupal 10 project that is controlled via composer.

Drupal's modular system allows for all kinds of additions to be added to your site through plugins, entities and configuration.

Thanks to Drupal's modular configuration system you can also inject custom configuration into existing configuration entities. This allows you to extend the functionality of an existing entity and ensure that any customisation are saved in the system configuration. Any configuration entity can be augmented without changing the existing configuration schema of the entity, which might cause knock on effects to other modules.

The Group module in Drupal is a powerful way of collecting together users and content under a single entity. These arbitrary collections of entities in a Drupal site can be used for editor teams within your site or company subscriptions where users can manage themselves, or anything that requires groups of users to be created.

During a recent project that used the Group module I found myself digging deeper into the Groups permissions system in order to achieve certain tasks. This is a similar permission system to that already created in Drupal, with the exception that the permission always forms a link between a Group and a user, and an optional additional entity. Permissions being local to the group is useful if you want to create groups of users that had access to pages and other entities that are kept within the group.

Drupal is a great platform to create communities of users where you can allow users to create their own content and interact with each other. One way of keeping users engaged on the site is by letting them know when other users are interacting with content they have created.

This is quite a common occurrence on sites like LinkedIn or Facebook, where you will receive a notification when a user comments or likes one of your posts. The same thing can be put together in Drupal with just a few modules (and a few lines of code).

In this article I will look at how to create a notifications system that will tell users about important events that they might be interested in. We will be using as many contributed modules as possible to do this, although there will be a small PHP class involved to tie some components together.

Performing behavioural testing on a Drupal project allows you to make sure that all of your features work as they should do. This is especially important when you update code as this can introduce bugs that are otherwise time consuming or difficult to spot.

One aspect that is important to behavioural tests is the content of the site, which is often integral to many Drupal sites functioning correctly. Many Drupal sites have taxonomy terms that are used in views to filter content in one way or another.

There are also structure pages that are used as signposts to other parts of the site, and they are often important in navigation. Whilst you could just visit the pages directly, it's often useful to test the user journey end-to-end, which involves being able to navigate to the functionality being tested.

There are a number of different ways to create a homepage in Drupal. One common technique is to create a content type to store the fields you need, with the addition of blocks to add extra information to the homepage layout.

Adding a content type to handle the homepage has a number of problems. It can be tricky to set up the permissions correctly for users to edit the page, also, it's easy to for editors to accidentally delete it and break the entire site. You often have to protect the content in some way to prevent unwanted editing or deletion.

Adding dynamic and interactive elements to a web page can be a challenge, and there are a few techniques available in Drupal to allow for this.

One solution might be to add a form to the page, but this can cause problems with the cache system. Adding forms actually makes it slightly difficult to cache the page properly and you can easily see poor caching levels from pages containing forms.

Rather than adding a form to the site (and the complexities that come with that) it is possible to create a fully dynamic element that can be used to perform actions by the user. This is done using a combination of different techniques, all of which are built into Drupal and just need to be plugged together.