If you're a frustrated web developer spending more time battling with Drupal than enjoying its benefits then read on, as I'm going to explain how I've hacked the Drupal site building process to make it easier and more fun.

I started exploring this process a couple of years ago. After years of Drupal experience, with it's ups and downs, something clicked. I thought I was in control before, but there would always be some part of a project where I felt like I was fighting with Drupal. I tried many different approaches, but once I found this methodology there was no looking back.

I've been developing this system for a couple of years, and in recent months I've started to see more people talking about it, conference sessions, and blog posts that talk about some of these ideas. None of this is unique, but I have pulled together various elements into a process, or system that anyone can use to simplify their Drupal site building.

In this article I hope to bring together a few key points that I think make the most difference to the success of a project.

My work in the past year has taken me into many agencies and I've worked with experienced Drupal developers, and with excellent developers but who were new to Drupal. On the one hand I've seen Drupal developers artificially constrained to produce "Drupaly" solutions because of perceived limitations of what's possible with Drupal, and on the other hand I've seen developers struggle to get Drupal to do what they want to do.

Perhaps you can relate to this story...

I went into an agency early last year to help with a late running project. There was nothing particularly unique about this website, other than it had some really nice design elements and was a stunning example of responsive design. But, hiding below the surface was a confusing Drupal implementation and a mess of spaghetti code.

Several developers had worked on the project, and it showed. Competing Drupal modules were being used to achieve the same thing in different parts of the site, the CSS used multiple grid systems, and the general lack of consistency meant the final stages of the project, bug fixing and cross device testing were proving difficult.

Requirements and designs had changed during the project, and so had the developers, which meant that rather than understand what had been done before, the developers hacked on extra bits of code, put in more and more CSS overrides to target specific elements to tweak the styles.

The result was a site that was proving impossible to get working across all devices, and as bugs were fixed, more were being introduced and discovered. Slight changes were having unexpected knock on effects across the whole site.

When I looked at the site, I congratulated them. They had produced a great prototype. They had gone a long way around to get there, but what they had done was understand the problem, and discover exactly what was required in a solution. This resulted in something that worked really well as a prototype. What they hadn't done was produce a production-ready site.

I helped them take a few steps back, which at the same time was a huge leap forward. With the knowledge they had gained we could work with Drupal to get the project completed, rather than battling against it.

What to learn from this?

Consistency is important, and prototyping helps to clarify what is required in a solution. Doing all the testing and bug fixing at the end of a project is hard, gets out of control, and causes missed deadlines.

Introducing Atomic Drupal

I've been looking at the emerging atomic design movement, component-based design, or style-guide driven development, and I've taken best practise from the cutting edge of web design and combined it with over 7 years experience of pushing Drupal to it's limits and past them.

Where I've ended up is a system for converting ideas into effective websites. A way of working with Drupal rather than against it, with the aim of shifting the focus of a project from development and bug fixing to solving new and interesting problems. Making the basics of site building easy and fun.

People I've introduced to this already have found they can now do more with Drupal and say yes to more of clients requirements, and work on more interesting projects.

Atomic Design

A component-based approach to the front end means creating more maintainable and flexible designs. There are a few tricks to getting this to work in Drupal, but the most important are: taking full control over Drupal's markup, and planning out a consistent approach to building the site.

Prototyping

An added benefit of taking a component-based approach is the decoupling of front-end design and development from the back-end CMS implementation. The biggest win is that you can build and test all your front-end code separately to the CMS build (you're not constrained to using Drupal's markup). This means you can test and validate your front-end code early on in the project, you can test across devices and browsers earlier in the process, and therefore not leave all your big fixing until the end of the project.

Workshop

Get in touch if you're interested in learning more as I am running workshops on Atomic design with Drupal for agencies and individual developers. Check my training page to see upcoming dates for public courses (at the time of writing the next scheduled public workshop is 24th April).

This workshop will cover how to take full control over Drupal's markup, resetting and removing Drupal's own markup and replacing it with your own. How to work with Atomic design and component based design principles in Drupal. Debunking the most common myths around Drupal front end code, and fixing the single biggest cause for late running projects and missed deadlines.

Book Ticket More info