Articles

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.

The Drupal Session Inspector module allows a user to view their current user sessions on a Drupal site. By allowing users to view this information you create a self-service security system where users can see if any unusual activity exists on their account themselves. The module also allows users to delete any sessions they don't like the look of, which protects their account.

This session deletion feature is especially useful in situations where the user has neglected to log out of a computer. They can just log into the site in another location and revoke that session, securing their account from accidental access.

As part of my continuing work on the Session Inspector module, I wanted to add an events system that could react to this deletion of sessions.

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.

Reflection is used to gather more information about code during the runtime of the program. This allows code to inspect itself and to make small modifications, which is useful in a variety of situations.

This is possible in PHP thanks to the reflection classes, which are built into core. PHP is capable of using reflection to inspect all types of classes, object, functions, variables and even the recent addition of Fibers. Using the reflection classes we can find out the internal structure of a class that an object is part of, including properties, methods constants as well as what sort of class we are dealing with. Reflection works even if the property of method is private or protected.

This post will concentrate on objects (and their associated classes) as the code used to inspect objects can generally be applied to other forms in PHP.

I use sites like CodePen and JSFiddle all the time to write JavaScript and CSS, but I've not seen a similar site for writing PHP applications. I have used 3v4l.org to test small scripts using different versions of PHP, but it doesn't allow dependencies to be added and doesn't have a nice editing interface.

Recently, I found a site called PHPSandbox that allows users to create PHP applications that can be run in the same way as applications on CodePen. This includes using composer to inject dependencies into the application and a nice little editor interface to see the output and logs from the application.