I tried to do something the other day that I thought would be quite simple, but turned out to be really hard to get my head around. I had a Drupal 9 site with Paragraphs installed and I wanted a user to click a button on the node edit form and inject a particular Paragraph into a Paragraph field.

I found 2 solutions to this problem that solve it in slight different ways.

Piggy Back On Existing Events

After my initial struggles over trying to get this to work I decided to use a piggy back method. This essentially listens for the user interaction and then triggers the Paragraph add event that inserts the Paragraph into the field. The user interaction I was listening for was a user selecting different elements in a select list.

To get this working I added some JavaScript to the page, attached to the select list field called "field_type".

For the last few years I have been tagging articles as I write them on this site. This tagging has largely been to tie posts together in an aggregated list of other posts tagged with that term. I recently wondered if I could use those tags to show related content below each article. I have struggled with this feature on client websites in the past and it either boils down to a manually curated list or some sort of complex content analysis and Solr search.

As it happens this is fairly easy to accomplish using Views, although took some working out to get the effect I wanted. I'm writing down these instructions to help me remember how I did it in the past and to allow you set up the same thing (if you wish).

I finished my last post on sorting colors using PHP looking at incorporating all three dimensions into the display of the colors. This lead to some interesting displays of colors in discs using different shapes or lengths as an indication of the color in question. It was still lacking actually rendering out the third dimension in any meaingful way though.

As I am essentially looking at three dimensional data I thought about displaying the data as a cube in a 3D engine. I could then map the three dimensions of colors (red, green, blue) into the three dimensions of the 3D engine (x, y, z). This means creating a 3D scene with random color data and rendering that scene out. Funnily enough, there aren't a lot of people writing 3D rendering engines in PHP so I looked into writing a very basic version that would just show point data.

I was looking at a media player on my phone the other day and was watching the waveform of the music shown on screen. This was a simple indication of the progress through the track and appeared to show quiet and loud sections of the track I was listening to. This got me thinking about how to extract this information as the media player I was watching must do this in real time in order to actually play the data, not just render this representation of the music.

After a bit of research into the MP3 file format I found that the file format is complex, but straight forward enough to process, so I decided to try and extract the data using PHP. I have seen a few techniques to extract the data from MP3 using PHP, but these largely involve applications like ffmpeg to convert the audio format into something like a WAV file, which is then processed.

Pushing data from Drupal into Solr is a really convenient way of creating a robust and extensible search solution. The Search API module has a number of different fields available that can be used to integrate with all sorts of fields, but what isn't included is computed fields or other data.

Thankfully, adding a custom field into the Search API system doesn't need a lot of code. A single class, with an optional hook, is all that's needed to het everything working.

I was recently looking at the node view count module that was being used to record what users viewed what nodes on a Drupal site. What was needed was a report page that had a bunch of data from different fields of a node, along with the node view count data. As this data wasn't immediately available to Solr I needed to find a way to inject the data into Solr using the mechanisms that Search API has. 

Drupal's login forms are protected by a protection mechanism that prevents brute force attacks. This means that if an attacker attempts to repeatedly guess a user's password to gain entry to their account they will be blocked before being successful. This system has been a part of Drupal for many years and so is battle tested.

Like all systems in Drupal, the flood system can be adapted to be used on your own forms. Which means you can protect any form that you don't want to be used too much. This will help with authentication forms or any form that might need to process lots of information where you don't want users to submit the form too much.

Before using the flood system on a form you first need to inject it into the form. Here is a basic form setup with the flood service injected into it.

I was working on a web page generation program recently and was looking for a way to present different versions of the same page with slight differences in the markup and styles. Although using the iframe element came to mind I wasn't keen on rendering out lots of different versions of the page and then referencing them individually in each iframe. I did think about creating using an API to send back each page on request but I thought that this might just overcomplicate the program.

After a little bit of research I came across the srcdoc attribute of the iframe, which solved the problem quite neatly.

The iframe is normally used with a src attribute, which points to some external page. The following example will render the page at example.com within the page.

A common design method is to use list elements to create the layout of a menu or a section on a page. This is all fine until the users come along and create lots of list items that mess up the layout of the page. In CSS it is possible to show only the first few items in the list so that your users can't mess up the layout.

To show only the first 2 items in a list use the adjacent sibling combinator to hide the third element and everything after that.

You can add as many li items to this list as you need to to ensure that the layout of your page works with the correct number of elements.

I'm a proponent of automation, so when I find myself running the same commands over and over I always look for a way of wrapping that in an alias or script.

I spend a lot of my day to day job in the command line and I realised today that I must have typed 'git status' for the millionth time and wondered what my most commonly used commands were. So I found a stack overflow post showing my most used commands in a nice little bash one liner.