Drupal

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.

This is the second part of a series of articles looking at 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.

In the previous article we looked at how to setup the batch process using a form, with the batch methods being contained within the structure of the form class. When the form was submitted the batch process ran through 1,000 items and then printed out a result at the end.

Whilst there is nothing wrong with running the Batch API with everything in a form class, it is normally better to abstract the batch processing code into a separate class.

The Batch API is a powerful feature in Drupal that allows complex or time consuming tasks to be split into smaller parts.

For example, let's say you wanted to run a function that would go through every page on you Drupal site and perform an action. This might be removing specific authors or removing links in text. You might create a small loop that just loads all pages and performs the action on those pages.

This is normally fine on sites that have a small number of pages, like under 100 pages. But what happens when the site has 10,000 pages, or a million? Your little loop will soon hit the limits of PHP execution times or memory limits and cause the page to be terminated. How do you know how far your loop progressed through the data? What happens if you tried to restart the loop?

Drupal's migration system allows the use of a number of different plugins to perform source, processing, and destination functions. 

Process plugins are responsible for copying and sometimes manipulating data into the destination. There are a number of different process plugins that allow you to get data in different ways and and apply it to your destination fields.

Both the core Migrate module and the excellent Migrate Plus module contain a number of different process plugins that you can use to process your data in different ways.

April 23rd, 2024 saw the first LocalGov Drupal Camp, held at the Birmingham Council buildings in Birmingham city center.

It's been ages since I attended an in person Drupal Camp in the UK, so when I saw that the LocalGov Drupal people were organising one just down the road for me I jumped at the chance to grab a ticket.

LocalGov Drupal is a distribution that combines Drupal, some configuration, some contributed modules, and some glue code with the aim of making it easier for councils to generate sites.

One of Drupal's strengths is its ability to create communities of users who contribute towards the content of the site. Whether you have an open forum, where users can create their own accounts, or a closed magazine with just a few editors your need to take the security of your users seriously.

Out of the box, Drupal has a number of account protection features that assist in making sure that users are authenticated correctly.

For example, the user login page is protected by a brute force system and will lock accounts after a number of incorrect password attempts in a short amount of time.

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.

This year's DrupalCon Europe was hosted between the 17th and 20th of October, in the French city of Lille. My DrupalCon adventure began early on Monday morning when Chris Maiden picked me up to drive to France via the EuroStar train. We arrived in Lille a little after 4pm, which was really good going for a nearly 400+ mile trip.

DrupalCon Lillie was a first for me as I was there representing Code Enigma, who had sponsored the event and organised a booth (well, a table). The booth wasn't so that we could sell anything, it was more more because we wanted to support Drupal and the sponsorship came with a booth. Driving to Lille allowed us to fill the car with 200 coffee cups, which we gave out at the event.