Drupal

This year, DrupalCamp Scotland was held on the 7th November, at the University of Edinburgh.

On the morning of the conference I made the quick walk from by bed and breakfast and arrived at 50 George Square to join in with around 60 attendees to a day of talks and chatting.

The morning coffee and a selection of pastries was set out in the corridor outside the main room of the conference. I'm sure a few of the tasty pastries were lost to passing students.

After getting settled in we had a quick introduction session by Stratos Filalthis before we started the day.

The Layout Paragraphs module is a great way of combining the flexibility of the layout system with the content component sytem of the Paragraphs module. Using this module you can set up a Paragraph that can understand different layouts and then inject Paragraphs into that layout, all within the confines of a single field.

What this means is that you users can build the layout they want within the edit pages of your Drupal site, without having to guess where Paragraphs will end up in the final site. It makes the site a little easier to edit and means that there should be less previewing of pages before publishing.

When working on a recent project I found that layout Paragraphs was in use, which wasn't a problem. The problem was that the site was quite simple, but had 12 different layouts to pick from. As a consequence, the pages consisted of a variety of different layouts that not only made the site difficult to edit, but also made the end result look a little messy.

Single Directory Components (SDC) consist of a directory of files that go together to create a small component on a Drupal website. SDC can be nested together, which means that a consistent set of elements can be created and plugged together on a site.

The power of SDC comes from their ability to be self contained. If you have the need to build a complex component that displays data in a widget then building it as a SDC means that you can ensure that every time you include it, the same widget will be shown.

It is possible to add an SDC to your Drupal site without adding them into tempaltes first. You can use the SDC Component Library module to preview them whilst you are building them, and then integrate them into your site once they are ready.

Single Directory Components (SDC) consist of a directory of files that go together to create a small component on a Drupal website. The component contains all the templates, styles, script, and images needed to display some content in a consistent way.

Different SDC can be nested together, which means that a site can be built up from different components working together to generate the content.

The power of SDC comes from their ability to be self contained. If you have the need to build a complex component that displays data in a widget then building it as a SDC means that you can ensure that it looks and functions in the same way every time you include it.

Hooks are used in Drupal to allow modules and themes to listen to or trigger different sorts of events in a Drupal system. During these events Drupal will pause and ask if any modules want to have any say in the event that is currently being triggered.

For example, hooks are commonly used when content is viewed, created, updated, or deleted. So, if we delete a page of content then a delete hook is triggered which allows modules to react to that content item being deleted. Using this, we can react to this and perform clean up operations on items of content that don't exist any more. Our custom module might want to remove items from a database table, or delete associated files since they wont be needed.

This is just one example of how hooks are used in Drupal as they are used in all manner of different situations, and not just listening for content events. Another example of a common Drupal hook is when creating a custom template.

LocalGov Drupal Camp 2025 was held in The Abbey Community Centre (near Westminster Abbey in London) on July 3rd 2025. I travelled down (despite the English rail network's attempts to the contrary) for the day as an attendee.

It was a hot day in London on the 3rd July, and thankfully the Abbey Community Centre had lots of doors and windows that we could open to let some air through. Including a few fans dotted around to try and keep the rooms cool.

After a small icebreaker, where people stood up if this was their first LocalGov Camp or what sort of role they have, we started the camp with an introductory session.

The first DrupalCamp in England was held this weekend (1st March 2025) in Cambridge. I drove down on the Friday with Chris Maiden to attend (and speak!) at the event.

We arrived early at the event and and started the day with a much needed coffee (or two) and started chatting with the other attendees.

The opening session was a keynote from Baddý Sonja Breidert, who talked about AI, the success of Drupal and the Drupal CMS system, and about the success of the Drupal community. 

Creating queues using the core queue classes in Drupal is fairly straightforward. You just need a mechanism of adding data to the queue and a worker to process that data.

As the data you add to the queue is serialised you can add pretty much any data you want to the queue, so the only limitation is rebuilding the data once you pull it out of the queue.

There are some situations where the core Drupal queue system needs to be altered in some way. You might want to separate the data into different tables, or have a different logic for creating or storing the queue items, or even integrate with a third party queue system for manage the queues.

When writing data to the queue database system Drupal will convert the information to a string using the PHP serialize() function. When the information is pulled out of the database the queue system will unserialize() the data to convert it back into the original information.

When you first start using the queue system you will probably use an array or the PHP stdClass object to store the information on your queue. Whilst this works, the information they contain is pretty free form and makes testing or working with the data a little cumbersome.

A much better way of storing data is by creating an object of a known type and using that as the storage medium for the queue.

I've talked a lot about the Batch API in Drupal recently, and I've mentioned that it is built upon the Queue API, but I haven't gone any deeper than that. I wrote about the Queues API in Drupal 7, but thought I would bring my understanding up to date.

A queue is a data construct that uses a "first in, first out" (or FIFO) flow where items are processed in the order that they were added to the queue with the first item added being processed first. This system has a lot of different uses, but is most important when it comes to asynchronous data processing. Drupal and many modules make use of the queue system to process information behind the scenes.

The difference between a queue and a batch is that the batch is for time sensitive things where the user is expecting something to happen. A queue, on the other hand, is more for data processing that needs to happen behind the scenes or without any user triggering the process.