Our blog

On a recent Drupal 8 client project our client was building listing pages using views exposed filters and adding these to the menu.

This resulted in several menu URLs pointing to the same base path, but with the query arguments determining the difference.

However Drupal 8's default menu-trail calculation was resulting in the menu highlighting all instances when one of them was viewed.

Luckily the active trail calculation is done in a service and it was simple to modify the default behaviour.

Read on to see how we did it.

PHPStorm has a lot of built in test runners, but it doesn't support Drupal's Simpletest test runner. In this blog post we'll see how we can execute Drupal tests inside PHPStorm using Drupal test runner.

Whilst working on a Drupal 8 project, we found that cache tags for a Block Content entity embedded in the footer weren't bubbling up to the page cache.

Read on to find out how we debugged this and how you can ensure this doesn't happen to you too.

Recently, I have been working on a site with a big multi-step form that is using a lot of custom form elements, custom auto-completes, custom form api states and ajax based sub-forms. It is all built using Drupal form api. The best thing about this form is that all the fields and sub-forms map to a data model.

A requirement that comes up from time to time is being able to use content stored in Drupal and produce rich HTML emails. In a lot of cases the design of these emails matches the design of the existing, already implemented front-end website.

In a recent project, we explored ways of creating HTML email’s which wouldn’t require us to start from scratch and would also evolve as the website’s look and feel did. Our design goals were thus:

• Use the existing website’s CSS to skin the emails.
• Use existing Drupal site-building tools to construct the markup for these emails.
• Allow admins to easily create and preview HTML emails.

One of the aspects of the new object oriented architecture in Drupal 8 is the introduction of services. Services can be provided by any module and provide a mechanism for exposing reusable functionality by way of interfaces and classes. All services are instantiated via the container which is responsible for injecting a service’s dependencies.

Since services implement interfaces and are always instantiated via the container, we have the opportunity to alter what the container returns, ultimately allowing us to swap any existing service with a new one.

For many agencies, and large organisations that have tens or hundreds of Drupal sites, it can be difficult to keep tabs on which sites have what modules installed and whether they are up to date or not. Manually crawling through each site can be time consuming and error prone.

In this post, I describe a solution that allows you to keep a dashboard of site status information that you can query to find out precisely what is going on on each of your sites.

In this blog post we will take you though all the components required to provision a high availability Drupal 8 stack on Microsoft Azure. This is an extract from the demonstration given at Microsoft Ignite on the Gold Coast in November 2015.