A sparkline is a very small line graph that is intended to convey some simple information, usually in terms of a numeric value over time. They tend to lack axes or other labels and are added to information readouts in order to expand on numbers in order to give them more context.

Sparklines tend to be around 20-30 pixels height and up to 150-200 pixels wide. The are generally best when you want to show between 5 and 15 items as adding more items to such a small graph can make things a little messy.

Drupal's modular system allows for all kinds of additions to be added to your site through plugins, entities and configuration.

Thanks to Drupal's modular configuration system you can also inject custom configuration into existing configuration entities. This allows you to extend the functionality of an existing entity and ensure that any customisation are saved in the system configuration. Any configuration entity can be augmented without changing the existing configuration schema of the entity, which might cause knock on effects to other modules.

The Group module in Drupal is a powerful way of collecting together users and content under a single entity. These arbitrary collections of entities in a Drupal site can be used for editor teams within your site or company subscriptions where users can manage themselves, or anything that requires groups of users to be created.

During a recent project that used the Group module I found myself digging deeper into the Groups permissions system in order to achieve certain tasks. This is a similar permission system to that already created in Drupal, with the exception that the permission always forms a link between a Group and a user, and an optional additional entity. Permissions being local to the group is useful if you want to create groups of users that had access to pages and other entities that are kept within the group.

I read The Daily WTF every now and then and one story about bad logging code in PHP stood out to me. The post looked at some PHP code that was created to log a string to a file, but would have progressively slowed down the application every time a log was generated.

PHP is a great language as it allows you to put together code without easily shooting yourself in the foot. One downside of this ease of access is that it can allow beginners to put together code that works, but will ultimately cause problems in the long run. The PHP code given in the post is certainly an example of this.

I know that the goal of The Daily WTF isn't to fix problems found in code and is more of a satirical look at bad coding examples. I thought, however, that it would be good to look at the code and fix the issues it had.

Drupal is a great platform to create communities of users where you can allow users to create their own content and interact with each other. One way of keeping users engaged on the site is by letting them know when other users are interacting with content they have created.

This is quite a common occurrence on sites like LinkedIn or Facebook, where you will receive a notification when a user comments or likes one of your posts. The same thing can be put together in Drupal with just a few modules (and a few lines of code).

In this article I will look at how to create a notifications system that will tell users about important events that they might be interested in. We will be using as many contributed modules as possible to do this, although there will be a small PHP class involved to tie some components together.

Performing behavioural testing on a Drupal project allows you to make sure that all of your features work as they should do. This is especially important when you update code as this can introduce bugs that are otherwise time consuming or difficult to spot.

One aspect that is important to behavioural tests is the content of the site, which is often integral to many Drupal sites functioning correctly. Many Drupal sites have taxonomy terms that are used in views to filter content in one way or another.

There are also structure pages that are used as signposts to other parts of the site, and they are often important in navigation. Whilst you could just visit the pages directly, it's often useful to test the user journey end-to-end, which involves being able to navigate to the functionality being tested.

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.