Having a web presence is essential for all businesses, and if the website contains a contact form then it is essential that it correctly sends contacts to that business. Contact forms are useful as it allows users to easily contact you directly through your website.

I have recently had a very frustrating time trying to get into contact with a number of different companies due to their contact forms not working correctly. I think the overall success rate was about 40%, which is a terrible response rate.

One company I (eventually) got in contact with were very thankful that I pointed out that their contact form didn't work since they wouldn't have known otherwise. They only realised after the fact that they hadn't been getting any emails.

I work on a couple of ThinkPad laptops (T490 and a P14s) and whilst they have fingerprint scanners I haven't really considered using them. I once attempted to get a fingerprint scanner working in Linux on an old HP laptop and that experience put me off trying again.

When I looked into the getting the fingerprint scanner working on a ThinkPad with Pop! OS installed it turned out to be quite easy. The drivers were already present so it was just a case of installing the correct software and adding my settings.

Drupal's path system gives authors the ability to override the path of an item of content. Whilst the internal path of a page might be "/node/1" the external path can be anything you want, and can be set when editing the item of content.

The addition of the Path Auto module makes this change of path easy for your users by using patterns and automatically generating paths based on the data contained within the content item. You might want to use a path that contains the type of entity being presented, what category it was added to, and even the title of the item of content.

This system creates powerful search engine friendly URLs that can add keywords to the paths that Drupal uses to find content.

When building custom entities there are a few things you need to do in order to add Path Auto functionality. It must contain a 'canonical' link that points to the entity and be a fieldable entity with a field called 'path'.

After creating tic tac toe in JavaScript in my previous article I decided to add a second player in the form of a computer opponent. One player would still place their tokens in the same way, but the other player would use an algorithm to determine the best play against you.

There are a few ways in which we can create the algorithm for computer player. The game of tic tac toe is known as a "solved" game, which means that the best play to make for any given move has already been worked out. We could, therefore, build an algorithm that matches the game current game board with the known state of play and then just place the computer piece in the most optimal place.

The downside of that approach, however, is that we need to enter in all of the different conditions of the board before hand. This means that if we want to change the rules or alter the size of the board we would need to enter in a completely different set of game conditions.

Tic Tac Toe (or noughts and crosses) is a good game to create when learning game development as it has simple rules and a known win state. I have created a version of tic tac toe using PHP before, but I wanted to see if I could re-create the game in JavaScript using the canvas element. This is certainly possible to do as everything we need is built into JavaScript itself, which means we don't need to import any packages to get this working.

In this article I will go through the necessary components needed to create a version of tic tac toe using JavaScript and a canvas element.

If you've ever looked at the settings in a digital camera, or have experience with image processing programs like GIMP, then you may have seen a colour histogram. This is a simple graph that shows the amount of different shades of colour are present in the image.

They are created by looking at the number of colours in a given image and them mapping their red, green and blue values against a the frequency of their occurrence in the image.

Colour histograms are useful for looking at the overall colour distribution within an image and can also be used to simplify the colours of an image by restricting how much of a certain colour is allowed based on its frequency.

In previous articles I have written about injecting context into context aware plugins and creating custom context providers and wanted to complete the series by writing about creating context aware custom plugins.

The context system in Drupal is a powerful way of injecting dynamic data into plugins without writing code to add that data directly to the plugin itself. Instead of adding custom code to find the current user or the node from the route of the page you can inject the context into the plugin using the context system and add code to make use of that data. Although most commonly used in blocks it can be found in a couple of other plugin types in Drupal core, like the condition plugin for example.

In this article I will go through how to create a context aware plugin, including how to create custom plugins and how to allow that plugin to understand the context_definitions annotation. Once the custom plugin is complete we will render it using a Drupal controller action to prove that the context works correctly.

I've been doing a bit of Drupal migration recently, and one of the tasks I have undertaken is to migrate "likes" from a Drupal 7 site to a Drupal 10 site.

The likes in the old Drupal 7 site were built using a custom module, with the Flag module was selected to provide the new functionality on the new Drupal 10 site. This meant that I needed to migrate the old custom structure into the entity structure provided by the Flag module.

To add further complication, it was possible to add likes to nodes and comments, which meant that the flags on the new side needed to be applied to two different types of entity. This was simple enough to do using two different types of flag entity; one for nodes and one for comments.

Context definitions in Drupal are really useful when you want to inject context into your plugins and I have been using them for a little while now. It has made building custom blocks to add content to pages much easier as I don't need to copy the same block of code to find an entity of a particular sort into the block plugin.

One problem I encountered when using this technique was when trying to programmatically create and render a block. The problem was that the context wasn't available in the block when it was used in this way, and it took me a little investigation to find out how to put all of the pieces together.

Rendering a block programmatically is sometimes a necessity to do when you need the block outside of the block's normal region. You might create a block that collects together the output of a number of blocks, which allows you to template them together in a very precise way. You might also need to print out a block without having to create a region on a page.

I previously looked at injecting context providers into context aware plugins. This time I will explore more about creating our own context providers to plug into this system.

The context provider system is an ideal way to provide context to context aware plugins, with blocks being the prime example. You would use a context provider to inject an entity or value into the block so that actions can be taken using that data.

For example, we could load the currently loaded node from the route object using the context so that we didn't have to bake the route provider logic into the block.

The values we inject also plug into the cache systems and so we don't need to worry about making sure we integrate the cache systems within the block system. That is all taken care of upstream.