Composer is an excellent way of managing dependencies but in order to use it properly it does require a build and deployment process.

The two ways of deploying a site built with composer is to either generate an artefact with the composer dependencies installed, or to install composer as part of the deployment process. Both of these approaches require not committing the vendor directory and other third party libraries (like Drupal core for example) to the git repository.

Many developers tend to go for the approach of committing the composer dependencies to the repository in order to simplify their workflow. This approach, while simple, does have its problems. I have talked about the problems of committing the composer vendor directory in detail in a previous article.

Google PageSpeed tool was created to give webmasters an indiction of how their site will perform when analysed by the Google search engine. As Google takes a variety of different factors into consideration when ranking sites the tool gives an indication of the health of the site.

The score it calculated using a percentage, with different bounds of the score being coloured differently. Between 0 and 49 is poor and is coloured red, between 50 and 89 is average and is coloured orange, above 90 is considered good and is coloured green.

Getting a perfect score in the Google PageSpeed Insights tool is by no means the end goal of site performance improvements or even search engine optimisation. It will absolutely have some benefits in terms of your site traffic though and is worth including in your site key metrics.

Timing web requests is possible in curl using the -w or --write-out flag. This flag takes a number of different options, including several time based options.

These timing options are useful for testing the raw speed of requests from a web server and can be an important tool when improving performance and quickly getting feedback on the response.

The -w or --write-out flag in curl has a number of different options, far more than I can add here. You can use these options by surrounding them in a "%{parameter}" structure and passing this as a string to the -w flag.

This is probably not relevant to some people, but I find that I'm always searching for this information when I need to print out a URL or find the current page path.

The difficulty is that finding or printing out a URL is very contextual and there is more than one way to get or use this information in Drupal. You might have a node object that you need to convert into a fully qualified path, or you want to print out the path of a route, each of which have different approaches. I think that's why there are so many questions asking variations of this topic on sites like Stackoverflow.

What is surprising to me is that there is very little documentation on drupal.org about this. Creating URLs and printing out links is perhaps the most common thing that needs to be done by developers creating themes, outside of changing the classes or markup of a block of HTML.

Drupal 9 gives you a lot of flexibility to place node fields into different areas of the site, but there are some limitations. You could use the field display manager to change the order and format of the fields, or install the layout builder module and organise fields into sections.

The problem comes when you need to display some fields outside of the limits of the node template. For example, you might want to show a header image within the page template, or print a curated list of links in the sidebar. These situations exist outside of the node template so you need a different way of adding those fields to those parts of the page.

There are just some situations where you just need to render out a field to a different part of the page.

Since starting the Session Inspector module I have been busy adding features to improve how the module functions.

One of these additions is the module now being able to retrieve and store the browser that the user is current using to access the session (also known as user agent string). This just uses a hook_user_login() hook and stores the browser using the standard session storage system built into Drupal. This browser string is then pulled out of the session metadata and presented to the user in the session inspector interface.

Whilst this provides the user with more information, the one big downside is that when accessing the session inspector page the user sees a browser string that looks something like this.

Mozilla/5.0 (Macintosh; Intel Mac OS X 12_2_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.109 Safari/537.36

Working with logic surrounding dates can sometimes be difficult and it's fairly common to come across really subtle date and time based bugs.

I was recently shown a bug in a PHP application that looks like it should be working at face value, but doesn't actually produce the correct result.

The issue in question was surrounding a date comparison. A collection of objects containing dates were compared in order to find those dates that were less than a month old. This worked fine in testing since all testing dates were less than a month old. After the system was in use for a number of months it became clear that the check wasn't working so further investigation was needed.

I recently had this idea for a new Drupal module that allows users to manage their sessions. The idea is that a user could look at their current sessions to see if any suspicious activity had happened on their Drupal account. They could then delete any sessions they don't like the look of in order to kill off that session.

The functionality I describe here is actually quite important as it allows users the ability to spot suspicious activity on their accounts. I have even used it in the past when one of my accounts was hacked. The fact that the session was opened from Brazil helped me inform the site that something was wrong.

I did some searching on Drupal for a module that did the same but didn't find anything so I thought I would create a module and go through the process of creation in an article. This includes the research into how this can be achieved in Drupal, looking at designing the interface, and then adding code to create the needed effect.

I was talking with a fellow programmer the other day about a poor test that we were reviewing and we got onto the subject of what makes a poor test. The test in question had a reliance on a previous test being run, and the problem we encountered was that on some systems the dependent test was run after this test, which caused it to fail.

This also caused some headaches in local development as it couldn't be run in isolation. We had to ensure that both tests were run, in the correct order.

After fixing the tests so that they could be run independently I created a list of some common problems that programmers might come across when writing tests. These rules can be applied to most coding test, not just unit tests or behavioural tests.

If you are working on the Linux command line then sometimes you'll do a search to find out how to run a command that performs a task. I don't usually copy and paste commands in unless I can see what is going on, which used to mean spending time going through man pages and documentation trying to find out what this or that flag does.

That all changed when I found explainshell.com, which will extract the parameters of a command and tell you all about what the different flags will do.