Articles

This problem came out of a recent project I was working on. I had to perform a bunch of API lookups on behalf of a user that could take a minute or so to complete. The results of the API lookups were cached and so once it was done the site would be very quick, unfortunately the initial API lookup slowed down the page load quite considerably so this created a problem.

Rather than just doing the API loading in the page load process and making the user sit through it I created a batch process to load the API results in a more manageable manner. This created another problem as although the batch runner in Drupal is really good, it is perhaps a little too much just to show to users and expect them to understand what is going on. This led me to think if I could run a batch process via an AJAX callback from the page they were trying to load.

Drupal's cache system is robust, feature full and extensible. It can be used to cache small blocks of rendered output or the results of more complex calculations. The cache can be stored in a for the page request, in a database or in a different cache system.

I recently needed to store a decent amount of data that was pulled from an API. Getting the data from the API took a few seconds so it was important to cache this within the site for quick retrieval. Even just storing the cache in the database was many times quicker than the API so it made sense to cache the results within the site. Having the user sat there waiting for the page to load every time they do anything isn't great.

To this end I created a small Drupal service that would manage this cache for me. Here is the record from the services YAML file within the module.

From the pages of 'crazy things you can do with Drupal 8' comes this idea that I recently had to implement on a site. This was on a site that had implemented translations, but they needed something a little extra. The central idea was that if you visited a page on the site in a particular language, and that language didn't exist, then to try and give the user a similar language.

If you weren't already aware, Drupal's default behaviour is to return the default language version of a page if the language requested doesn't exist. If the Path Auto module is installed (which is usually the case on most Drupal sites) then Drupal will not be able to translate the path alias correctly and will issue a 404 if the requested translation doesn't exist. Drupal can't take the path for the French page /fr/about-us and find the original node because as far as it's concerned /fr/about-us doesn't exist.

On the weekend of 2nd and 3rd March I went down to London to attend DrupalCamp London 2019. This weekend I went with 9 other colleagues from Access, which is almost certainly our biggest company outing to a camp.

For a long time the drupal_set_message() function has been a mainstay of Drupal development. You can use this function to print a message or an error response to a user. This is useful to do as it can be done almost anywhere before the final page rendering functions and will be printed into the same area of a Drupal page.

This has recently been deprecated in Drupal 8.5.0 and so I was looking around on how to do the same thing in a new way. Drupal now has a messenger service, powered by the class Drupal\Core\Messenger\Messenger. This can be included into your code using the following shortcut.

$messenger = \Drupal::messenger();

This can be used to print messages to the user. For example, to print a standard message with a blue background do the following.

$messenger->addMessage('Message printed to a user.');

This can be done in one line like this.

A while ago I was working on some changes to a website and came across a block of code that made me stare blankly at my screen. The website I was working on was a custom build website, created by another developer at the company I was working with at the time. I have never done a PHP:CSI on this site before but remember being so amazed at what I found at the time that I made a note of it for future reference. I have pondered recently how to approach the analysis of the code.

The code I found was in a method that inserted an item into a database table. For some reason that I can't fathom the developer had opted to not use auto increment ID's and has instead developed a method that essentially randomly decided on an ID number for the item.

I can't paste the entire block of code here, but I can include the region of code that made me scratch my head in bewilderment.

Colourising images is fairly simple to accomplish, especially using PHP's GD library. All we need to do is load an image, create a blank image of the same size in a particular colour and then merge the two images together.

In fact, we can do this entirely with the imagecopymerge() function, but creating a function to wrap all of this makes sense as well.

The following function takes an image resource (as created by imagecreatefrompng()), the red, green, and blue values of the colour, and the percentage to overlay the colour on top of the image. The percentage can be set to 0 for no effect and 100 to fully replace the image with the given colour.

From the drawers of "I didn't realise how complicated that was" I was wondering the other day how to draw a line using just pixels. This turned out to be more complicated than I thought.

Normally in PHP you would use the imageline() function to draw a line between two points. The following block of code creates and image and draws a white line from the coordinates 50x,50y to 200x,150y.

// Generate image resource with a width an height of 250 pixels.
$im = imagecreatetruecolor(250, 250);

// Create a colour.
$white = imagecolorallocate($im, 255, 255, 255);

// Draw a white line from 50x,50y to 200x,150y.
imageline($im, 50, 50, 200, 150, $white);

// Write the image resource to a file called line.png.
imagepng($im, 'line.png');

// Destroy the image resource.
imagedestroy($im);

This creates an image that looks like this.

Part of the process of putting a new site live can be moving DNS entries around. Prior to doing this it's a really good idea to sort out the Time To Live (TTL) of the DNS record so that when you do change DNS entries you aren't waiting around for a day for the DNS to sort itself out. Most DNS registrars will allow you to set your TTL down to a minute or so.

It's also very important to check the status of your DNS records to ensure that they have the correct TTL, usually a day before (and day of) the move.

You can check the TTL value of your A record with the host command. Change the value of the -t (type) flag to aaaa or cname to inspect different types of records.

host -a -t a www.hashbangcode.com

This will produce the following output. The TTL of the domain below is '125'.

Whilst it is possible to view the contents of an SSL cert from within most modern browsers I occasionally find the need to use the command line to find out the same information. I find this useful when renewing certificates as browsers can occasionally cache certificates for longer than expected, causing false results.