Articles

Following on from by previous post about sorting colors I decided to take another step towards sorting colors by segmenting the data to create a further dimension to the multi-dimensional array.

The array is already split into segments based on the hue of the color, but we can further split this by separating out saturation and value into separate arrays within hue. To do this we set the saturation or value to be a constant and push them into separate arrays.

The new code looks like this. Please excuse the duplication of code here. This is just a simple example to show how the array is put together.

The last time I looked at sorting colors I had produced a nice band or sorted colors, but to do so I had essentially removed a third of the data from the color information. This meant that there was no white or black colors in the band of sorted colors.

After a bit of thinking on how to solve this I hit upon a way of using a two dimensional array of colors to filter the colors into blocks. This would allow the missing color information to be rendered correctly, and would only mean a small amount of work to allow it to work with the rendering function used in the previous examples.

Generating The Data

I could easily just generate every color available and use that as the data. What I wanted to generate was a random assortment of colors that would represent the sort of data being produced by a system or other input.

I recently wrote a post about setting up a multi-site configuration setup using the Configuration Split module. That post was written after I did research into how to set up configuration splits and use them to create multi-site setups in Drupal. One thing I realised when doing that research was that although it's quite easy to get setup with that kind of setup, it's also easy to get it wrong and create a setup that really doesn't work.

Setting up a Drupal 8 site for a multi-site environment with a common configuration isn't too hard, it just requires a little bit of forethought and some planning to get things right. You need to have a default configuration in mind, and then think about how each site can override this configuration in different ways. I have seen it done wrong a few times recently and once you go down the wrong path, getting things back in line again can be a difficult.

The default configuration covers things like content types, vocabularies, fields, views, enabled modules, or anything else that would make up the structure of the site. Each sub-site would override this by adding configuration for theme components, custom block placement, or anything else that is custom to that site.

When developing sites in Drupal 7 I found the hook_init() hook was a good way of quickly testing certain things in code. By adding little blocks of code it was possible to build complex SQL queries, inspect internal configuration, or even test complex node interactions.

When I started to develop sites in Drupal 8 I found that I needed a similar mechanism to do similar things. However, the hook_init() hook doesn't exist in Drupal 8 any more so I needed to look at another way of doing this.

In order to do this in Drupal 8 we need to utilise the event subscribers. There are a few different types of event subscribers available, but in order to use them we need to create a little module.

Here is the info.yml file of a module called hook_init.

The Shield module prevents access to a Drupal site by putting a Apache authentication system across the entire website. This means that to access the site you need a username and password.

This is useful in a number of different situations, but I use it most for protecting dev and staging sites from access. It's not the most complex authentication system in the world, but it's enough to prevent the embarrassment caused by having staging sites being spidered by search engines.

SOLID is a set of object oriented design principles aimed at making code more maintainable and flexible. They were coined by Robert "Uncle Bob" Martin in the year 2000 in his paper Design Principles and Design Patterns. The SOLID principles apply to any object oriented language, but I'm going to concentrate on what they mean in a PHP application in this post.

For the second year running I attended BSides Manchester conference, held at the Manchester Metropolitan University Business School on Thursday 16th August. This is a technical cybersecurity conference that is organised by a dedicated team of volunteers. I was really impressed by last years conference so was really keen on attending this year.

I've been using PHP for a number of years and have seen the same things being done with return values from functions over and over again. I have always thought of this as pretty standard, but the more I think about it the less it makes sense. Looking back over my career I am quite sure that a few serious bugs could have been avoided if I had not mixed return types.

As PHP is a loosely typed language this gives the developers the ability to change the type of value that is returned from a function. This happens quite often within the PHP codebase itself as many built in functions will return false if an error happened.

A common practice in userland code is to return false from a function if something went wrong. This might be because it is encouraged in PHP itself.

I wanted to impart a piece of advice to do with validation and formatting of user input, although I've never seen anyone suggest it. I guess it would come under the single responsibility principle so it might seem obvious to some people. There can be reasons why this might at least seem like a good idea at the time.

Essentially, if you want to validate that something is correct, don't format it at the same time. These two actions should be done in separate functions or even classes. I hope to demonstrate that using a single function validate and format anything is a bad idea. I'll mainly be using PHP to demonstrate this, but the principle should be pretty much the same in any language.

Take the following function called isValid(). This is an arbitrary and simple example but shows validation and formatting in use in a single function.