Drupal 11

This is part three of a series of articles looking at HTMX in Drupal. Last time I looked at using HTMX to run a "load more" feature on a Drupal page. Before moving onto looking at forms I thought a final example of using HTMX and controllers to achieve an action.

One of the key examples that helped me understand HTMX was when it was used to create a tabbed interface, without reloading the page. This was quite simple to recreate in Drupal and can be done in a single controller.

In this article we will be creating a tabbed interface in Drupal, where HTMX is used to power loading the data in a tab like interface without reloading the page.

All of the code contained in this article can be found in the Drupal HTMX examples project on GitHub, but here we will go through what the code does and what actions it performs to generate content.   

Following on from my last article, an introduction to HTMX in Drupal, I wanted to start looking at examples of HTMX being used to power interactivity in Drupal in different ways.

I thought a good place to start this off would be to look at using HTMX in a simple controller. By creating a route to a controller we can render content and then inject HTMX attributes to perform actions with the same controller.

In this article I will put together a controller action to load some pages of content to display them as a list. An element containing HTMX attributes will be used to make a request back to the same controller action and generate more items in the list. These new items will be appended to the existing list along with another element containing HTMX attributes that we can use to request more items.

HTMX is a JavaScript library that allows you to make ajax calls and create CSS transitions without writing any JavaScript code. It works by adding attributes to HTML elements, which it then uses to set up and perform ajax requests, swap elements, and a few other things.

It was added to Drupal in version 11.3.0* and gives developers the ability to create interactive elements using render arrays and HTML attributes. The intent is to replace the entire ajax sub-system with one built around HTMX, and there is quite a lot of work ahead to accomplish this task.

* Technically, HTMX has been in Drupal since 11.2.0, but only as an experimental library. Drupal 11.3.0 features the full HTMX library and a number of helper classes to make life easy.

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.

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.