Articles

A development environment is an essential part of any web development project. It allows the website to be run outside of the production environment so that features or bugs can be worked on without disruption to the live website.

I've used local development environments to build websites for a number of years and I have striven to adhere to a set of rules that make life easier. These rules aren't a rigid set of requirements, but following them can make life easier for everyone on the development team. I have seen developers spend many hours with broken local development environments that could have been better spent actually working on the project.

I started to put together these rules after I inherited a website project from another company. This website came with the requirement of using a certain local development stack, which was required for the hosting provider.

There are a number of different ways to create a homepage in Drupal. One common technique is to create a content type to store the fields you need, with the addition of blocks to add extra information to the homepage layout.

Adding a content type to handle the homepage has a number of problems. It can be tricky to set up the permissions correctly for users to edit the page, also, it's easy to for editors to accidentally delete it and break the entire site. You often have to protect the content in some way to prevent unwanted editing or deletion.

Adding dynamic and interactive elements to a web page can be a challenge, and there are a few techniques available in Drupal to allow for this.

One solution might be to add a form to the page, but this can cause problems with the cache system. Adding forms actually makes it slightly difficult to cache the page properly and you can easily see poor caching levels from pages containing forms.

Rather than adding a form to the site (and the complexities that come with that) it is possible to create a fully dynamic element that can be used to perform actions by the user. This is done using a combination of different techniques, all of which are built into Drupal and just need to be plugged together.

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.