Drupal

I've been running this site for about 18 years now and the code I post has been in much the same format since it was started. The code is rendered onto the page using a <code> element and (mostly) syntax highlighted using a JavaScript plugin.

I make use of sites like Codepen and JSFiddle quite a bit, and often link to those sites to show examples of the code in use. Those sites got me thinking about the static nature of the code examples on this site. I have been writing more front end code recently, but static code examples aren't the best way of showing these features in action. I can (and have) uploaded images and gifs of the feature in action, but those images are many times the size of the code examples in question and serve only to bloat the page.

What I would really like to do is allow active code examples, or a code sandbox, to be injected into the page. This would allow users to interact with code examples rather than them just being static. A valuable learning tool for any site.

A common request I see when theming Search API forms is to swap out the normal submit element with a magnifying glass icon. Performing this action isn't difficult, but it does require adding a couple of operations to add a suggestion so a custom template can be used.

When I set up a view to perform a search against a Search API index I normally create an exposed filter for the text content. Views shows this as a block that can be embedded into the site. The block, however, comes with a input element to act as the search button, and it isn't possible to turn this into an icon.

By changing the input element to a button I can then inject a small SVG of a magnifying glass or similar to act as the search button.

Following on from my article looking at the Pimoroni Plasma 2350 W I decided to do something interesting with the Wifi interface that would connect to a Drupal site.

The firmware of the Plasma 2350 W from Pimoroni comes with an example that connects to a free API to update the colour randomly. Once I saw this in action I realised that it shouldn't be too hard to convert that to pull the data from a Drupal REST service instead.

It is quite easy to create RESTful services in Drupal; it just needs a single class. All I would need to do is create a form to control the colour that is selected in the REST service.

I encountered an issue on a Drupal 11 site recently where I had a block that was rendering an entity to display on a page.

There was nothing unusual about what was going on in the rendering process, but in this case I needed to add some attributes to the entity markup and I found that this process wasn't that simple. The solution was to intercept the rendering process half way through using a pre-rendering callback method.

As it wasn't that simple I took some notes and decided to convert them into an article to show how to do the same. In this article we will look at using the view builder to generate a renderable view of an entity and then look at how to alter the attributes of the view mode without using a preprocess hook.

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.