Articles

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.

It's that time of year again (Decemberween) so I was looking around for a set of addressible LED string lights to set up.

When you get a set of LED lights from your local supermarket they will often be either a single circuit or a set of multiple circuits. This means that they are either all on, or can alternate in a set number of patterns. This is frankly rather dull.

What supermarkets don't have is addressible LED string lights. In these lights each LED on the wire can be address individually to set the colour or brightness. You can tell if the lights are addressible as they will have three cables, two for power, and one for communicating with the lights.

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.

HTMX is a JavaScript library that can be used to issue AJAX requests, create CSS transisions, and set up web sockets using HTML

The power of HTMX is that it can be used without writing any custom JavaScript code. It works by looking for attributes in HTML tags using that information to set up events, user interaction, and send requests to a back end. The system is backend agnostic and so will essentially work with any system that can accept, interpret, and respond to the requests.

I have been meaning to look at HTMX since hearing about as it seemed like a decent system with a good community. Since then it has been included into Drupal 11.2.0 and there are plans to make it the core system for AJAX requests going forward. As a result it has jumped forward in my list of things to look at.

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.