Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Jul 14 2021
Jul 14

Option 1: Rebuild

Rebuilding in Drupal 9 is the perfect option for companies who wish to continue to get the absolute most from their online presence. It does require effort - both on the part of developers and the company itself - to ensure that the resulting system matches the business objectives in order to maximise effectiveness and ROI.

Rebuilds work best when they are backed up with proper discovery and design phases, and do not rely on historical design patterns from past iterations. As mentioned above, rebuilding in Drupal 9 is the last major rebuild required, as Drupal’s new semantic versioning makes all future upgrades far less onerous.

Option 2: Minimise

The minimise option is for those who may wish to have all the engine-room clout of Drupal 9 behind their site, but for whom it is not the right time for a full rebuild.

In this case, an option might be to minimise the feature set and build a ‘minimum viable product’ - i.e. a core website with a limited feature set, which can be expanded on in the future as business needs arise. You could liken it to 'bridging' between an old system and a new system.

Option 3: Decouple

A decoupled approach is not a conventional solution, but in certain cases could make sense. Decoupling means that the “front end”, as viewed by the public, is separate and distinct from the “back-end”, which stores the data and which would be used by website editors.

In this scenario, you could feasibly firewall off an old Drupal 7 system from the internet, but allow it to feed data to the front end for consumption by visitors. In this way, you could continue to use an established system well past its end-of-life, allowing editors to continue using an interface they know, and data structures with which they are familiar.  The front end is typically a ‘static’ site, which usually means that it is fast, secure, and requires minimal maintenance.

Option 4: Reassess

The ‘reassess’ strategy is where a company reconsiders what it wants out of its digital presence. Possibly business objectives have changed, or KPIs dictate another direction, or possibly even digital is the obvious only game in town. 

This strategy is all about making deliberate, informed decisions about how to invest in your company’s digital identity and your customers' digital experiences. Outcomes could range from a minimalist approach through full rebuild or even as far as a digital experience platform.

Option 5: Redistribute

In a redistribute strategy, a company might take a legacy monolith site which does many things, and break it apart: splitting functions and features across specialist services across the web.

For example, you could use a shopping platform for e-commerce, a GIS platform for mapping, a storytelling platform for rich engagement pieces, etc. In this scenario, a minimalist core website might tie together several disparate specialist services.

Jun 11 2021
Jun 11

Drupal 8 Made Everything Better

From the beginning of Drupal 8, everything in the lifecycle just got better - including moving to Drupal 9 and beyond.

Design and research have not really changed, but once you begin to build, you start to see the changes. Drupal 8 and 9 are far more feature-complete, requiring far fewer contributed modules. With an elegant configuration management system built-in, it is straightforward to keep all settings in version control.

Beginning with Drupal 8, there is now a planned and continuous improvement release cycle for new versions of Drupal. This means that new features don’t have to wait for a full new major release: instead, they are incrementally included in new software releases every 6 months.

From a typical release page, they say “This minor release provides new improvements and functionality without breaking backward compatibility for public APIs”. Some examples of new functionality which have come online through this process include, media handling, content workflow, layout builder, to name but three.

As before, minor upgrades are straightforward, but the most significant change is that major upgrades no longer require a complete rebuild of your site. As only deprecated APIs are removed in each major upgrade, upgrades can now be completed in a fraction of the time. In fact, most are completed in a matter of days, and not months as before, and usually with only minimal effort on the part of the site owner.

A site redesign can also be performed at a time dictated by business needs, and does not need to be coordinated with a 3rd party release cycle. 

Aug 19 2020
Aug 19

Drupal 8 was released in late 2015, heralding a significant departure from its predecessor, Drupal 7 and required a complete re-build. 

However, the benefits of moving were evident early, and companies who decided make the jump were glad they did so.

The benefits included:

  • Ease of use - in-place editing, using CKEditor 
  • New theme engine, using Twig
  • New Symfony Framework
  • Enhanced multilingual capabilities
  • Extensibility - enhanced capability to integrate with third-party systems
  • Better performance - using BigPipe technology that loads pages quicker
  • Media library - browse and reuse media across your site
  • New features - new features are released every 6 months

But the big news was that there would be no more major re-builds – you didn’t have to re-build the site for future upgrades, new features will be carried out in smaller updates.

Though Drupal 9 does not offer any new features in its initial release, it does offer a leaner, more secure system with APIs that are easier to work with - these changes are most noticeable to developers.

Future releases of Drupal 9 will continue to feature additions and improvements along the six-month release timeline that has been established with Drupal 8.

Apr 03 2020
Apr 03

Previously I wrote about the hidden power that resides in the hands of a designer. Here are 10 questions you can apply to a supplied design, and the answers to them, or even the process of getting those answers, can bring a good design through to being a great design for your project. Remember, a design is just a picture until it is implemented, and it is important that the technical implementation is considered at the design stage.

1) Image Sizes

How many image sizes are there across the site? How many different aspect ratios? Is there any commonality between images? Where can we reuse an image? In Drupal terms, we're asking: Can I use image styles? How many do I need? In which area of the site can I use each image style?

If there seems to be no obvious pattern, it can be worth articulating the benefits of using standardised image styles to the designer, such as performance and improved editor experience.

Remember that with a responsive design, images will usually stretch to fill a space, so image styles will generally set an image to its maximum required width. The single most important thing to consider is aspect ratio. If all the images have the same aspect ratio, then the implementation of a design becomes much, much more straightforward.

2) Content Order

In a responsive site, as screen size diminishes, chunks of content flow around each other and jump below other content to accommodate the smaller screen width. It is important to realise that designs for smaller screens are sometimes supplied without due regard to this flow of content. If you see content order on a mobile design that doesn't match up with that in the desktop design, ask about it. Either it is a mistake that is easy to rectify at the outset of the project, or it will turn into a monster that will eat your budget.

3) Horizontal Alignment

People love horizontal lines. They particularly love columns of content, with line breaks, each of which line up with its neighbour in the next column. Unfortunately, the web, and responsive design in particular does not make such a design easy to implement.

It is bad practice to set absolute heights to elements in responsive design, to allow elements to expand as necessary, but without control of heights, any content change or width change will break the layout. As widths decrease, the height of content in a restricted space increases, which means that either the content will overflow its bounds, the content will be clipped, or the container expands, breaking the nicely arranged horizontal alignment.

There's no easy solution to this, so it is important to bring it to the attention of all concerned early on, lest it become an issue late in the project when deadlines are tight.

Often this issue only comes to light at launch time, when a client is putting real content, and replacing the nice, consistent three lines of dummy text in the design.

Ask how much content should be in the space. Ask whether the lines need to line up. Ask whether you want to rely on brittle Javascript to make heights equal. Ask early.

4) Long Titles

In a typical design, in my experience, titles and teaser text will be short, bordering on terse, lending themselves to smart, ordered layouts, and small containers in which to fit these elements.

When a site is live in the wild, titles can be really, really long. Editors are given content, control over which they may not have. The design has to accommodate this situation. Try swapping out
'Lorem Ipsum Dolor Sit Amet.'
'Many editors struggle to fit their content into the cramped confines of a small title block.'

Then see if the design still works. Ask about maximum title length and the ebb and flow of text on the web.

What happens with a long title on a small screen?

5) Large, Full Screen Background Images

Do you really need it? How big is it in kilobytes? Is it worth the extra page weight? Can the weight of it be reduced by blanking out where the content will live? What happens on small screens? Do they need to download it?

Think of performance, think of the value of that background image, and think of mobile users.

6) Fonts

What fonts are in use? Are they special? Is there a cost associated with them? Do they have all the necessary characters in the font? (e.g. I recently had to use a font that had no ampersand character.) Does the client know about any cost? Are they happy with that? Where are webfonts in use? Are they just for headings? Or are they for body text? Do they work on cheap, low-resolution screens? (If they don't, it's probably a poor choice.) Is the 'Flash Of Unstyled Text' before the webfont loads acceptable? How much does the font add to the page weight? Can you use a subset of the font? Do you need bold, italic and other variations?

7) View Modes

How many different ways is the same content (e.g. a node or a bean) viewed on the site? Where on the site are these places? Each different representation directly corresponds to a View mode. If there are many variations, can these be rationalised? View modes are immensely useful, but there comes a point where YAVM (Yet Another View Mode) becomes painful. Less is more.

Another consideration here is seeing if view modes can be shared across content types. For example, is the listing page for news posts the same as the listing page for events? If so, we can use the same view mode for both? This will cut down on the time needed to style these view modes with CSS.

8) Configuration

Does the client need to configure anything? What does the site editor want to be able to change? Should footer blocks be editable? Or any of the site chrome? Should only the main content area be editable? Should the site editor be able to modify listings? Panel Pages? Forms?

The answers to these questions are relevant because they directly affect how you approach a build.

(Aside: read our article The Drupal Content Editor deserves and easy Life.)

9) Browsers

What browsers need to be supported? Can the design even be properly implemented in older browsers? What does 'graceful degredation', or 'progressive enhancement' look like in practice with this design? Which design elements, e.g. funky CSS3 effects or killer Javascript libraries, won't work in poorer browsers? Is there a fallback? Should there be? Ask about analytics. What are the actual site visitors using?

The older the supported browser, the more it will eat into your budget, and the older you go, the more it will eat.

10) Colours

How many shades (e.g., of grey) are there in the design? Can you tell the difference between them? For lighter shades, can you even see them on a poor screen? You can bet that the design was put together on a high quality, high resolution, bright screen. Does it work on a low budget, 10 year old 15" LCD screen? If colours cannot readily be differentiated on such a device, then they may be surplus to requirements.

Further Reading

Josh Riggs' excellent presentation from Drupalcon LA on creating great design without a huge budget.

Would you like to create something beautiful?

Ask us about it.

Oct 15 2019
Oct 15

What a UX designer thinks will be quite different from what a mechanical engineer thinks, which will be worlds away from what an artist thinks.

For example,

  • I am a trained civil engineer. As an engineer, design is in providing the minimal technical solution that fits the brief.
  • I often work in the role of a (web) site architect, where design is in accurately modelling business data to provide efficient and scaleable solutions.
  • I was never great at graphic design as my photoshop-fu is weak, but I always understood that as a graphic desiger, design is in creating beautiful interfaces for people to interact with.

As a developer, which takes up most of my daily work, I take website designs created by others and implement these into real, usable, functional software. I'm going to talk about things I have seen on real projects, with real clients and perfectly competent teams, where the design actually hindered the build process.

Building The Foundations, Out of TNT

Design can easily make or break a project, and graphic design is easily the most impactful of all design processes. From this point on, any references to 'design' will refer to web design, the graphical design of a web site, such as is often delivered as a Photoshop file (.psd) for implementation by developers.

I have seen great projects with great project teams really struggle because a design, whilst beautiful, was very difficult to implement. Conversely, a design that facilitates ease of implementation can make the project a joy to work on, and will result in a happy client and success all round. Site owners love something that they can 'sign off' on, and more often than not, the first thing that is signed off is the design, which can become a Bible against which the entire project is measured. It is little wonder that design can have such wide-ranging implications.

Deep Impact

There are many ways in which design can impact upon a project.

It's a safe assumption that a website will be built upon a content management system (CMS) - in Annertech's case, we use Drupal. The CMS will have a way of doing things, and the design can work with it, or the design can hinder it.

Nowadays, every site should be a responsive site. But does your design naturally lend itself to being responsive? This does not mean that as a designer you should create separate designs for multiple screen-sizes, but rather that a given design should naturally adjust and flow for different devices. In fact, having a separate design for mobile and tablet-sized screens to desktop can actually hinder development because of inconsistencies of design elements across Photoshop files. Without a solid understanding of how devices interact with and render a page, how page elements float and stack and expand and contract, you run the risk of a design that requires undue effort to force onto a small screen, resulting in a sub-optimal end product. When designing adaptive layouts, content order really matters too. The natural order and flow of DOM elements (if you are not a developer, read: "things on the page") should not have to be adjusted based upon screen width. To do so adds unnecessary complexity and will again probably impact upon performance - how quick your site is rendered on a screen for users.

An Artful Work of Fantasy

Sometimes a design will show visual effects that CSS simply will not produce. Whilst often these effects can be created with enough Javascript and imagery, often the trade-offs (maintainability, performance, page weight) are not worth the gain. Mobile performance, especially, can fall victim here.

A Font is Worth 1000 Pictures

Any designer worth their salt will tell you that font choice is hugely important. This is undeniably true. But the following things are often forgotten when choosing fonts:

  • A font can add considerably to page weight, depending on how many weights/styles you include.
  • On large and complex pages the Flash of Unstyled Text (the screen showing default fonts before the correct ones get to load) when using javascript-based font-replacement techniques can by very jarring. It can also be rather slow to go away on older browsers/machines.
  • Fonts can be expensive, and clients do not always want to pay for them. The smart money says: find out what the font budget is before you do your design. For example, a Photoshop design showing Proxima Nova (€615.99) will never look like a site built using Arial. This will cause untold friction between developer, designer and client over the build process.
  • Not all fonts are created equal. Some fonts might look lovely on a crisp MacBook Pro with retina display, but make sure you look at them on Windows, with a shoddy old 17" monitor. Often that is quite a different experience.

50 Shades of Grey

Great design is all about subtlety and attention to detail. However, this should not deliver a licence for the inclusion of unnecessary detail.

For example, a consistent and concise colour palette is a thing of beauty. However, more than a dozen shades of grey, many indistinguishable from one-another to the lay user, is merely an expensive waste. Again, try out the design on a low-budget monitor: can you tell the difference between #ffffff and #f4f4f4? If not, you probably don't need that level of subtlety and should simplify your design. Yeah, that's right: shots fired in the Needless-Shades-of-Grey wars.

To put it another way, consistency of design elements is a really powerful tool in a web designer's arsenal. Consistently presented elements, re-used in a logical manner, can endlessly simplify CSS, speed up site builds and improve performance. Clearly this is a desirable outcome!

An Appeal for Sanity

Speaking as a developer, this is my plea to designers everywhere to think about how your design can be implemented. Every addition to the design will have an impact on the build and probably on the end user. Is it necessary? Will it enhance or hinder? The ideal is design in the browser, so that you can mock up interactions, see how DOM elements (again, "things on the page") react to changes in screen width and look at what CSS can achieve and what it can't. This is not about asking the designer to do development, but rather to ensure that the agreed-upon design can be practically implemented.

Shucks, as a designer, you might even ask the developer "hey, any problems implementing this before I ask for sign-off from the client?".

Website owners: It's Up to You

Prospective site owners: people who would like to get a Drupal site built. This appeal I direct to you: "Do not accept the artful work of fancy."

There are two possible scenarios stemming from an impractical design.

  1. If you get the design before contracting a development team, the price will be higher than otherwise, as the design makes it more difficult.
  2. If the design is late and the developers have already begun, the project will be late as the effort required will be far greater than originally estimated.

Rather, ask for a design that works with your choice of CMS. One that facilitates responsiveness. A design that is not unnecessarily complicated. These are often the most beautifully simple, accessible designs. Everybody wins.

Love Your Developers

This final plea is one directly related to Photoshop. It is an amazing tool, and one that facilitates wonderful-looking sites. However, I open PSDs with dread. But it does not have to be that way. Herewith, a couple of tips to make the dev in your life happy:

  1. Name your layers. Names like 'Layer 35 Copy' make developers sad. We who are not conversant with the mysteries of Photoshop really find semantically named layers useful! (such as "Sidebar block, heading")
  2. Apply your layer effects. Unless one actually possesses a copy of Photoshop, one cannot see layer effects. Gimp and Preview won't parse them. Be nice to your devs and apply the effects to the layers that require them so that when we slice up a layer, we get the colour you intend and not a pale imitation.


Modern websites are really complex, and it takes a team of dedicated, skilled people to create them. The designer is often the first onto the green field site, and is arguably the person with the most far-reaching power. I suspect that many designers simply do not realise the depth and breadth of their power.

I think that in an absolute ideal, a designer would work alongside the developers, rather than rather than handing over "signed off designs", to create a site that is a harmonious thing of beauty.

Let's work together.

* No sites were harmed in the writing of this blog post
** Whilst all examples come from real life, names have been changed to protect the guilty parties
*** We'd love some cake, if you're sharing

If you want to discuss Annertech helping you build an award-winning website, please feel free to contact us by phone on 01 524 0312, by email at [email protected], or using our contact form.

Mar 30 2018
Mar 30

This is not a new phenomenon, and is testament to the efficiency and professionalism of the Drupal Security Team that these vulnerabilities are found, fixed, and the releases managed appropriately.

The release meant we had to update every single client site quickly, across multiple versions spanning Drupal 6 to Drupal 8.5, so our team immediately swung into action, developing a plan for each site. 

We've got your back

On Wednesday 28 March, around 8PM, the new versions of Drupal were released. Our team were poised, fingers on keyboards around Ireland, the UK and France, and rather than panic in the face of a large, time-sensitive job, we set to work.

Over the next couple of hours our shared spreadsheet tracked all the updates, steadily turning green as site after site was updated. Chat, jokes and on-mission discussions flowed freely through our chat channel as the team worked with one mind and one goal. In truth, it was a fun and exciting evening! By midnight we surveyed the end result: 70 sites updated, development and staging environments updated, and one redesign project even deployed to the live server!

1 team, 70 sites, 6 versions, no problem

Every member of the Annertech team did us proud, and because of our efforts on Wednesday evening, not a single client site of ours remained vulnerable to the exploit. Job well done!

Have you updated yet?

If you have a site that is not yet updated, and you need help doing it, don't delay: please get in touch - we'd be glad to help.

Nov 18 2016
Nov 18

Man, it's gonna be great!

But then a little voice pipes up: 'It's too complicated! We're trying to do too much! Can't we simplify this?' Nobody wants to listen to the nay-sayer, and the project proceeds apace. In due course, the complicated and extensive nature of the project begins to take its toll. Budgets run dry. Completion dates make a faint whizzing noise as they fly by. And yet the project isn't finished. Cracks appear, bugs sneak through and by the end, you just can't wait until it's over. The love of your life has turned into a horror-show that is slowly leeching the joy from existence.

The little voice, long forgotten, can no longer even be heard.

Let's do things differently! On time, on budget, in scope and on point. Wouldn't that be lovely? One important strategy on any project is the championing of simplicity. For any given item, be it design, feature or content, is to ask: "Can this be simplified? Is it currently over-complicated?"

Simple does not mean Stupid

A simple site need not be one that is devoid of functionality. Nor is it one with an overly simplistic data model or information architecture. It is one which has had the fat trimmed from it; it only includes the elements that are actually needed. Often it is in the identification of the actual needs and the elimination of flights of fancy that the greatest challenge and real rewards lie.

Simple is not Ugly

A simple design will capture the elegance of form, forgoing the unnecessary in the pursuit of perfection. In this era of responsive design, simplicity shines. Single column, full width designs are far more readily made responsive than more complex designs. Accessibility also benefits from simplicity. Naturally, the fewer tricks, hacks and workarounds used to bring a design to light, the more likely it is to be accessible by default. Also, with less thinking needed for the actual design implementation, it leaves more room to build the site in such a way as to benefit the most people.

Drupal is rather opinionated in the way it expects you to build your website's theme. That can be a frustrating experience, if you have not learned how it works. However, imperfect as it is, the theme system is very, very powerful and can actually help a themer to realise that design dream. The simplicity champion says: work with the system, don't fight it. Figure out the Drupal way and make it work for your design. Simplicity lends itself to theme harmony.

Lastly, minimalism as a design school is a beautiful thing, albeit sometimes difficult to achieve. Simplicity strips away the noise from a design until you are left with just the signal.

Simple will not be Useless

Simplicity includes the functionality that people need to get things done. It eliminates the things that people never use. You might look at eye tracking or click tracking data to figure out what people use and iterate your design to improve it over time. Real data from real users is invaluable for this process.

A simplicity champion will also reign in the wilder ideas of functionality: for example, maybe you don't need full, continuous, synchronous communication between your CRM and your website. Maybe one-way communication (i.e. web-to-lead style communication) would actually be sufficient. Or maybe periodic data imports from the site meets all the requirements, in which case the site only needs to be able to export data.

A simplicity champion will not be blinded by a request that comes tightly coupled with a suggested solution, but will reach beyond to figure out the real core requirements and design solutions to meet those.

Simple will be Beautifully Functional

On a massive scale, Google is simple. In effect, it's a one page website with only an input field and then some results returned. But at heart it is beautifully functional. You type in your request, it gives you back suggestions. We love this approach and try to make it work on all projects that we design and build. Take, for example, the www.housing.gov.ie website of the Department of the Housing, Planning, Community and Local Government. A limited colour palette, simple fonts, a simple layout... and a great-looking site that works across devices and transforms what was once a highly complex maze of documents into a very easy to use, information rich asset for the department and all its customers.

Overly Complex is always Expensive & Difficult to Maintain

Complex sites are not only more difficult and costly to build, but this trend continues throughout the lifecycle of the project. With many moving parts, changes need to be planned with greater care and tested far more extensively in order to avoid unintended consequences. Even supposedly simple changes can become large enterprises. Sometimes complexity is unavoidable and that is fine: all these hurdles can be overcome, but it is worth considering the long term effect of your design & requirements choices at the beginning of your project. Your site is not just for Christmas.

Websites Are Like Whiskey

Minimalism is the art of stripping back everything unneeded until you are just left with the core of necessity. In this way, a minimalist site can be thought of like a good whiskey. On the surface, it's simple to look at and made of only a handful of ingredients. But its minimalist appearance belies the depth of complexity present in the process through which it is distilled into being. Skilled craftspeople with decades of knowledge put their love of their craft to use to build you the ultimate product.

Just like excellent whiskey, excellent websites are the product of a process honed over thousands of hours of experience, resulting in beautiful, simple sites that are a joy to use.

Would you like to benefit from our crafting process? Contact us to chat about how we can bring the beauty of simplicity to your project.

Oct 05 2016
Oct 05

This year's DrupalCon was not different because of the happy coincidence that had Annertech scoop a raft of awards at the Realex Web Awards on the Wednesday (including "Web Agency of the Year"), but rather because of engagement and involvement.

Before the 'Con even occurred, the local team was preparing content, answering questions and, in my case, writing the 24 Hour Guide to Dublin. Seeing my work laid out beautifully in print in the DrupalCon programme was an unexpectedly great pleasure!

As a local, I had the opportunity to MC a keynote Q&A session. That was enormous fun, made all the more fun by a fantastic speaker, Emer Coleman. Coming off stage was a rush, lengthened by the deluge of interaction on Twitter as I was mentioned and our conversation bounced around the DrupalCon Twittersphere.

There was also the personal interest in both other keynotes as Annertechies took to the stage to chat to their speakers - Mark Conroy speaking to Dries at the "DriesNote" and Alan Burke chatting with Eduardo Garcia during the "Community Keynote". Suddenly it was not merely about entertainment any more - I cared. It had become relevant to me. I met Emer on Tuesday, in advance of the keynote, which meant that I was excited about it for most of a day of Drupalcon before even taking to the stage!

The DrupalCon prenote is always good fun - and I was several years in before I even discovered it! This year, taking part in it was very rewarding - from getting to know Jam, Cam, Adam and the crew a bit better, rocking out with the O'Drupals band, endless 12-bar blues in between rehearsals and finally being part of a very entertaining half hour show, I really felt that I was now part of the community. And I definitely made new friends who I'll be looking out for next time!

It was my first time to give a session at DrupalCon, speaking on the topic of "Happiness is ... Remote Working". I had spoken at camps and at Dev Days in Dublin, so public speaking was nothing new. But at DrupalCon, surrounded by my peers, talking to people at the top of their game, in a room full of people far cleverer than I am, it was a brand new experience. Andrew put it best: "Level unlocked!"

Although it was my first DrupalCon speaking slot, I had submitted talks for several years before and it made me think about what I had been doing wrong. Firstly, one must be able to prove that one can speak, so camps, Dev Days, Front End, other conferences and speaking opportunities are all good ways to beef up your speaker CV. Evidently I'd managed to convince the program team that I had cobbled together enough experience. Secondly, I read the track descriptions, and submitted sessions that attempted to deliver the things they were asking for. This is something I had neglected in years past: I would decide on a talk, write it up, and only then read the track descriptions (or even just the name!). Obviously, delivering what the program team wants is the most important hurdle. Here's the video of my talk:

Sep 15 2016
Sep 15

Choosing proper hosting for your site shouldn't be a race to the bottom.

Hosting websites is hard. Websites themselves are complex, global traffic can mean huge numbers, big spikes in activity and always demanding users. Sites need to be served quickly, consistently and reliably. Downtime costs money, effort, and more than likely a few extra grey hairs too.

Choosing hosting for your website can be a daunting prospect. You've invested time, effort and money into developing your creation, of which you are justifiably proud. Now you need to find it somewhere to live. But where?

Hosts come in all shapes and sizes, from cheap shared hosting environments for about a euro a week, up to specialised infrastructure platforms catering to massive distributed applications.

Here at Annertech, we offer expert, Drupal-optimised, managed hosting.

  • Expert because we know Drupal inside out. Expert because the server administrators are at the top of their game, using best-in-class tools and technology to provide rock-solid and reliable infrastructure for your sites. Expert because our hosting utilises the power of version control and provides development environments identical to your live setup, to maximise confidence in any changes. Expert because we are the only agency in Ireland with a member on the Drupal security team.
  • Drupal-optimised because our hosting comes tuned to get the best out of Drupal, and is bundled with all the performance enhancing extras you can imagine such as caching layers and reverse-proxy engines.
  • Managed because you don't need to worry about server software updates, application layer updates, server configuration, or any of that jazz. Managed because, importantly, we take care of all your Drupal core and contributed module security updates for you.

Security updates alone make this arrangement make sense.

For example, take a site with, say, 100 contributed modules. You could reasonably expect to have to deal with around 20 security updates during a year. Monitoring for security releases, applying updates locally, deploying to a test environment (you have one of those, right?), testing, and then replicating those changes to the live environment all takes time. Then there's all the server level software updates and patches. That could turn out to be a lot of headache.

Maybe you have a support contract with some lovely developers (hi!) who do your security updates. That's a great way to handle it, but wouldn't it be even better if your developers spent their time improving the features of your site?

Simply by hosting your site with Annertech, security updates become a non-issue. Saving you stress, time and money.

Give your lovely new website a nice, secure place to live. Talk to us - you'll be glad you did.

If you'd like to discuss hosting face-to-face, we'll be at Booth 901 at DrupalCon in Dublin.

Mar 29 2016
Mar 29

You're working on a client's existing site, and they ask for some new functionality. Your first thoughts are: "Yay, some work!" Quickly following that you think: "What do they want? How am I going to build it?" The often unasked question, however, is "How can I integrate this new functionality with what they already have, without making maintenance a nightmare, or even worse, impacting existing functionality?"

This is a tough ask, as the new feature has the potential to reach across multiple pages, content types and styles.

We can build it!

For simpler features, it's easier to confidently introduce the new parts. For example, if your client wants a blog, you know that you can create a blog content type, give it an image field and a taxonomy reference field for tagging, and you're almost done. Build a couple of views displays and wrap the lot up in two features. One hook_update_N() function later and you have a scripted deployment to add your new blog articles, listing, tags and menu items in a single  drush updb command. Easy, right?

But even with this simple example, what about theming?

The example assumes that there's no particular theming requirements for the blog articles and listing, and that the theme will handle all of the elements gracefully. But if changes are required, how do you prevent inadvertent CSS bleed from new style rules over into existing content types. Equally, if new styles are introduced, should they apply elsewhere on the site? Should, in fact, any new blog-related CSS live in the module layer, with the definitions of all the functionality, keeping all the related code together? Or should we dive into the theme and add styles that would become redundant if the blog were ever deprecated?

These questions deserve consideration, and I fear that they are often ignored, with a blasé "of course CSS goes in the theme!" attitude.

There is evil there that does not sleep.

Let's talk about Webform.

The Webform module is amazing. It is really powerful and allows site builders and site managers/editors to quickly craft complex forms for capturing and storing data, reporting on that data and even allows limited workflow functionality.

But for many business cases, the out of the box functionality simply is not enough. They want to be able to take payments and to sell things - tickets, time, etc. They want to be able to prepopulate fields with values and modify form elements based upon other field values.

Now we need to start really thinking.

We can modify form elements with hook_form_alter() - that's fine. But how do we limit it to webforms? OK, we can use the Form ID - it has the form 'webform_client_form_NID' so we can look for that. But each webform has a different numerical ID, so how can we limit our customizations to just a certain form, or a certain subset of forms? This is where we can get messy and we need to remember that this functionality is for life (well, the life of the project), not just for Christmas. However we do this, it needs to be maintainable.

Possible solutions.

If we want to identify a single specific webform, we can use its Node ID, which is an obvious choice. We can put that NID into a variable and into settings.php, which avoids hard-coding the NID into the functionality. The drawback of this method is that NIDs can change between environments, so your donation form might have a different NID on your development environment than it does on the live environment. This, at the very least, complicates deployments.

If we want to modify a subset of webforms, maybe we can use a content type. For example, Webform can be attached to any content type, so we can easily create a 'donation form' content type and make our modifications to any webform of type 'donation form'. In this way we can manage separate functional modifications to other forms, e.g. event registration or lead generation. This too works, up to the point where the site owner wants to combine both your donation/payment functionality and your event registration functionality into one form. How does one rationalise and implement such a request? And how do you then limit this combined functionality to specific forms? Are we back to square one with node IDs set in settings.php, and its attendant maintenance nightmare?

There has to be a better way.

I quite like to use fields to bring configurability to new functionality. A couple of fields in a vertical tab field group lends a nice air of a proper settings form to your node edit page. Once you interrogate your node for the values of these settings fields, you can then control your custom functionality at a per node level, which is a really neat thing to be able to do from both a site admin and site maintenance point of view.

The problem here is that you've two separate items that are tightly coupled: your nifty new module/code and field configuration updates to any content type that you want to make use of it. You then need to bear in mind that you need to maintain the Features for any such content type. It would probably be worth bringing this logic to its natural next step, creating a Feature for all the Field Bases of your new fields, guaranteeing that they exist and are consistent with the machine names expected by your custom code (and more easily allowing field bases to be shared across content types/features without conflicts).

Somewhere, over the rainbow

Here's my version of the Holy Grail: imagine a system where you could indicate on a settings page, which custom functionality should apply to which content types, and settings controls would then magically appear on the relevant node edit forms... As of this writing I have not seen a working model of such a system, but I can dream.

Maintenance of your site should never be far from your thoughts when introducing new features/functionality. As Support Lead for Annertech, I have to deal with a lot of legacy code, and therefore think about these things a lot. If you'd like to chat about support for your Drupal website, or ongoing development in a sustainable, maintainable way, give us a shout.

Feb 26 2016
Feb 26

Oxfam Ireland wanted a faster site. It was already pretty performant, especially for a high traffic site, chock-full of features, but with the ever upward march of mobile usage, performance rose to the top of the want list.

Why do you want a fast site?

The reasons are many, and often not even on a site-owner's agenda when planning a site. Here's a few:

  1. Slow pages cost you conversions (AKA money!). Research back in 2006 by Greg Linden showed that every 100 millisecond delay in page rendering time resulted in a 1% loss of sales for Amazon. 
  2. Google prefers faster sites, so it impacts on your search rankings
  3. If you're on a mobile device over a dodgy connection you just aren't likely to hang around waiting for a slow page to load. Face it, you'll get bored and load up Twitter instead.

What counts as fast?

How fast is fast? Well for that matter, what counts as a page load? When is it 'done'? There's lots of tools and lots of metrics. e.g.

  • Actual time to finish loading a page
  • Time to first byte i.e. when the first packet (piece) of information hits your browser.
  • Time to usable - this is where everything on the page is not loaded, but there's enough core content there to keep a user happy while the rest finishes downloading.
  • onLoad event - this is a Javascript event that fires when all the Javascript is loaded and therefore all the bells and whistles should work.
  • Perceived performance - this is more nebulous, but arguably the most important thing to consider. How fast does the site feel to the user? Does the important stuff at the top load quickly and first so they have something to look at? Can you click around whilst the rest loads?

We've done a bit of a deep dive on performance testing here, if you want to know more. 

How we made Oxfam's website faster

Performance is not binary. There are a lot of variables to consider. When speeding up oxfamireland.org, we took a three-pronged approach.

  • server infrastructure.
  • Drupal tuning
  • a home-page redesign.

Each of these avenues of attack improved matters and each one worked in tandem with the other two to achieve measurable, demonstrable speed improvements.

Server Infrastructure

This was arguably the easiest improvement to implement. We moved the site from a dedicated, generic, virtual private server to our high availability, high performance platform. Tuned specifically for running big Drupal sites, our hosting environment comes fully loaded with a Varnish reverse-proxy server and Redis (an advanced key-value store) for lightning-quick server response.

In addition to simply putting the site on our platform we also made a few changes at Apache level, to better serve certain elements of a page, for example, compressing SVG files as they were served.

Drupal Tuning

Within the guts of Drupal we found plenty of small wins. We:

  • disabled some unneeded modules.
  • deleted other modules that had found their way on to the site but remained unused to reduce the amount of PHP that had to be parsed.
  • isolated and solved small, otherwise inconsequential PHP errors and notices to relieve pressure from the database
  • minified HTML, JS and CSS to reduce page weight
  • moved as much JS as possible to the bottom of the page so that it would not block other elements from loading
  • ensured that no modules were setting unnecessary cookies that might interfere with Varnish

Home Page Redesign

Home pages are notoriously heavyweight. Typically, home pages tend to have rich multimedia experiences, laying out a site's wares up front in the hope that a user can easily navigate to any part of the site from there.

Heavy pages take ages to load. Pages with lots of images take longer to load. High resolution, uncompressed images squished into a carousel/slider exacerbate slow loading. Throw in a good helping of Javascript and you're unlikely to see your page load this side of the weekend.

Whilst we wanted to improver overall load time, the real win was to improve the perceived usable state, i.e. the time to having usable content presented on the page and bring that down as low as possible.

With the home page redesign, we had the following aims:

  • Reduce the number of page elements. In terms of designing for speed, less is more. So fewer images, fewer styles, less Javascript, etc. Every added element will have a performance impact.
  • Following on from this, reduce the number of HTTP requests. Every HTTP request involves the overhead of a round trip from client to server and back again. Fewer requests means a faster page.

Drupal allowed us to combine CSS files and Javascript files to minimize their numbers and squish them through minification and compression to reduce their file-size. We looked into using image sprites and better using image-styles in order to optimize both the actual size and file-size of images.

The single biggest change was in getting rid of the hero image slider on the home page. This single element involved multiple large images and simply by removing that, it allowed a single smaller masthead image and text to load quickly and efficiently at the top of the page, so that it is the very first thing a user sees. This gives the perception of a really lightning fast site.

So how did we do?

The combination of all these techniques, each one a small gain, led us to a very nice 15% increase in overall page speed and more importantly, a massive 50% improvement in time to perceived usable state.

In an organisation where performance directly relates to numbers of donations which in turn directly affects the lives of the poorest people in the world, every millisecond counts.

Oct 19 2015
Oct 19

Technical debt occurs when you take a shortcut, thinking "this will do for now. I'll sort it out properly later." And then you keep putting off "later", and probably forget about the issue ... until it comes back to bite you.

It's all those tiny things like a misspelled variable, whose misspelling has to be replicated evermore, or making a configuration change on a live site without capturing it in code, so that the live site is now different to the development one.

It's going [copy]-[paste] to a chunk of code when you really should be abstracting it into its own function.

It's neglecting coding standards. Even 'just this once', making your code harder to read and understand.

It's adding a */

Jul 22 2015
Jul 22

Hacked sites. Security flaws. Lost data. Loss of trust. Lost customers. Lost revenue. Nightmare.

Just thinking about themes such as these in the media can send a shiver down your spine. It can all seem very daunting, and not just a bit scary when you start to think about it. This article aims to paint a clear picture of what you should be aware of as a site owner - where security weak points are, and strategies to avoid them.

My Website Has a Password - That Makes it Secure, Right?

Security, like the technology behind a modern website, has many facets and layers. Alas, merely password protecting your site admin screens is not enough. Having said that, I do remember, in the bad old days, being presented with a site without even that, such that anyone who guessed the admin URL could edit all the site content.

Unlike back then, security is now a serious business and needs to be treated as such.

Starting from the first point of contact and working down, the security layers are:

  • Password protected user accounts
  • Appropriately set permissions for user accounts
  • Protected forms
  • Secure file location
  • Securely written site code
  • Up to date site code
  • Up to date server applications
  • Up to date server operating system
  • A secure location for your server
  • Encryption for traffic to and from your site

User Accounts

It may seem obvious that a strong password is important, but alas, people don't seem to take this very seriously, as evidenced by this article from TechCrunch.

Fortunately, there are Drupal modules to help avoid chronic passwords, e.g. Password Policy and Password Strength to name but two.

A password is only half the battle, though. Drupal ships with a powerful and fine-grained permissions system that allows a site administrator to dictate what users can and cannot do. It is critical that proper attention be paid to user permissions when setting up a site or introducing new features.

Protected Forms

Following on from user account permissions, forms, e.g. content editing forms, comment forms, contact forms, should all be viewed as potential areas of attack and need to be locked down. The safest thing to do is simply restrict who has access to a form. E.g. only site editors can post new content. But in the event that other users can use forms, strategies to limit the potential for harm include: using a text filter on text inputs so that no potentially harmful tags, such as

Jul 13 2015
Jul 13

Previously we wrote about connecting your website with external systems, and specifically, the benefits of connecting your site with your CRM . As with many problems, there are many ways to approach this.

Over the years we've completed integrations with Salesforce, Microsoft Dynamics CRM, Goldmine CRM, SugarCRM, CiviCRM and even other, more esoteric systems. Different clients have different needs and different systems have different ways of doing things. Here are a few ways we've connected up sites with CRMs.

Note: I'm using the term 'integration patterns' to describe approaches we've successfully implemented in real life. You may have heard of the term 'design patterns', which are solutions to software design problems you find again and again in real-world application development. This is something similar.

All these examples come from real life, but whilst an example might refer to a particular CRM, e.g. Salesforce, it could be just as applicable to another system, e.g. Dynamics.

Example Integration Patterns

Website Lead Generation

(example using Salesforce)

With this pattern, the website acts as a data capture mechanism, generating leads for Salesforce. When a user submits a form on the website, the data is instantly sent to Salesforce and a 'lead' object is created. This is known as 'web-to-lead'.

  • Communication is one way: web -> Salesforce
  • Whilst data comes from the web, once it hits Salesforce, Salesforce becomes the canonical data source
  • It is up to the Salesforce administrators to decide what to do with the data once a 'lead' is created. They may set up some sales automation business rules, or they may wish to have a human review each lead and decide the next step
  • It uses Salesforce's REST API

This is one of the simplest integration patterns.

Member synchronisation

(example using Salesforce)

This is a pretty complex scenario. As with the last example, Salesforce remains the canon, as it is with Salesforce that the business users interact on a daily basis. However, in addition to capturing contact data on the website and sending it to Salesforce, members can log into the website and view and update their data.

  • Communication is two-way
  • Website captures information for new and existing contacts
  • Upon update in Salesforce, contact data is sent to the website and member profiles are updated
  • A unique identifier for the Salesforce record must exist in the website user profile
  • A unique identifier for the user profile must exist in the Salesforce record
  • We used Salesforce's SOAP API, but could now use their REST API as an alternative

Customer Contact Data Capture

(example using Microsoft Dynamics CRM)

This pattern captures data and uses it to create data objects, e.g. customers, purchases, etc in Dynamics.

  • Communication is mostly one-way: web->CRM
  • CRM becomes the canonical data source as it is used organisation-wide
  • A middle layer sits between the CRM and the website, which takes submissions from the website and processes them into something Dynamics can use to create objects. This middle layer provides the API that the website can use.
  • Where an object must reference another object, e.g. a purchase and a customer, the API layer can perform a lookup to get IDs of objects in CRM so that the new object can be created.

Web-based Contact Database

(example using Goldmine CRM)

In this pattern, Goldmine is the one true source of data, and the website publishes it in a user-consumable fashion.

In a perfect world, where Goldmine is accessible over the internet, Goldmine would expose its data at a URL. From this URL, Drupal would fetch the data, parse it, and create or update nodes as required for display. Mostly, however, Goldmine exists inside an office, and is not accessible. In such circumstances, the Goldmine pattern is as follows:

  • Query the Goldmine database and produce a CSV file
  • Upload that file to a specified location known to the website
  • The website parses that CSV file and updates, creates or un-publishes its content as necessary
  • Parsing a CSV file is relatively straightforward. The tricky part can be the automation of the data extraction from Goldmine and subsequent upload to the web server.

Customer Contact Data CRM

(example using CiviCRM)

CiviCRM does integrate tightly with Drupal, but sometimes using it to power the user facing elements of the website is not desired. In this case, CiviCRM provides its own API to allow Drupal's forms to insert data into CiviCRM itself. Extension modules for Drupal can also allow this.

Because of the very tight integration that already exists between the two systems (CiviCRM relies on the Drupal platform to work), getting data into CiviCRM is straightforward, and then the data can be viewed/manipulated with CiviCRM's own interface.

Customer data export

(example using 3rd party CRM application)

This is where a custom report is created to extract customer data from the website, in a specific defined format, such as CSV. This CSV file can be produced on demand. It can then be imported into the 3rd party application through its own import facility.

This is not a great way to connect the two applications as it involves manual steps and is difficult to automate, but it can be valuable when no other solutions are available, or as an interim measure until something more robust can be put in place.

Contact data exposed for interrogation

(example using 3rd party CRM application)

This pattern is similar to the data export above. In this pattern a custom database table is created and populated in addition to Drupal's normal tables. This custom table is configured to an exact specification, so that a custom query can take that data and feed it to a 3rd party CRM application.

The custom table is used as an interface: the CRM's query does not need to know anything about Drupal's internal structure, but yet is able to effectively pull data from the website as needed.

Built-in CRM

(example using RedHen)

Finally, here's a great alternative to connecting your website to a separate CRM, which is to actually build your CRM into your website. RedHen is a native Drupal CRM solution, fully utilising Drupal's power to be flexible, extensible and full-featured. Having your CRM built-in means that there are no network issues, no failed transactions, no lag and no wondering about whether that donation has made it through to the CRM yet. If it's on the website, it's already there, in the CRM.


Have you proper integration with your CRM? If you'd like to accelerate your organisation's efficiencies and bring it to the next level, contact us.

Yes - I want to connect to my CRM!

Jul 06 2015
Jul 06

Modern websites talk. They talk through great content to the visitors who come to read them, but they also talk through APIs (Application Programming Interfaces) to other systems. Does yours? Should it? Could integrating your site with other systems bring you greater return on investment?

Your website can potentially talk to a plethora of other systems, such as your CRM (and here's why it should), your social media presence, your finance applications, other websites, forums, 3rd party apps and mobile apps... the list goes on.

Chatty Systems

You might be like any of these examples:

  • John captures leads via forms on his website, and sends the results through to Salesforce where he's got sales automation business rules which fuel his whole sales pipeline.
  • Mary has both follow and share buttons for her social media presences. Her embedded social media timelines draw fresh content to her site and she can update her social profiles with content directly from her site.
  • Joe has a webshop and a separate finance application for doing the accounts. He has a feed which exports data from his shop and goes straight into his accounting package, saving tons of time.
  • Síle wants her content to appear in multiple places, so she has exposed it via an API so that mobile applications and newsreaders can consume it. Now her adoring public can consume her content any way they choose, increasing her readership.
  • Bob has an active forum community. Users of his website are logged in automatically to the forum, and can pass from site to forum seamlessly. Bob's real goal, however is tighter integration, so he is considering Drupal's Harmony  as a pure Drupal solution for his forum.
  • Judy wants a richer content experience, so she tags her content with taxonomy terms powered by WikiData - a database of well known people, places and things. This allows her to not only control her vocabulary without editorial overhead, but also to access rich data within the context of her own content and enhancing it.

Joining The Dots

There are many ways to connect sites to other applications. Some sites, e.g. social ones, often supply ready made embed code which you simply copy and paste onto a page. Simple, yet effective, this is very common. You can get tighter integration by employing some more specialist modules, e.g. Drupal's Twitter module, which 'provides API integration with the Twitter microblogging service'.

Some other third party applications provide a public API you can talk to: e.g. Trello or Freeagent or Wikidata.

Often APIs are accessible over a communication method known as 'SOAP' calls, but it has become more common for these to be over RESTful interfaces, which simply allow normal URLs, like a web address to have functionality attached to them.

Why Bother?

When visitors come to your website, no longer are they simply thinking 'What can I read here?', but rather they are thinking: 'What can I do here?'. Read? View? Download? Comment? Interact? Create? Buy?

The same should apply for site-owners. 'What can my website do for me to make my life easier, or otherwise bring me benefit?'

Integrations with other systems can bring that to life. If your website can feed your CRM up to the second live lead data without any copy and paste, that is simply immense. Equally, if you can get your financial transaction data from your web shop into your accounts package simply and reliably, not only are you saving countless person-hours of tedium, but the overall quality of your data will be far greater than that achieved by a laborious, error-prone manual process.

Gotchas & Things to Consider

In any information exchange process it is important to consider the workflow before you begin. You need to answer questions like:

  • Is this a master-slave relationship, where one system holds the canonical data for both systems?
  • Is the data-transfer one-way?
  • Can one system write to the other (push)? Or must a system request data and do its own writing (pull)?
  • What happens if the data on the systems diverge?
  • How does validation work? Do both systems have separate validation rules for data? Do they run over an API? Do they even agree? (they really should!)

For example, say you have a CRM and a website, and they both contain contact data. Which is the one true source of contact data? Does the website merely capture contact data (e.g. in a shop)? Do users have access to update it thereafter? What happens in the CRM when the website gets new data?

Equally, if CRM data changes? What happens on the website? Nothing? Or is it updated based upon CRM?

Lastly, what happens if communications fail? Is there a Plan B? Is there a log? Can the system re-try the transaction in the event of failure?

All these questions need answers, or else, your Plan B might end up more like this.


One very important point to close on is this:

Make sure you have expert support for your chosen CRM on hand before you begin any integration project. I can't stress this enough. Your project will go more smoothly, it will be faster, and you will end up with a better product that better fits your needs once you engage with experts at both sides of the equation.

We've been doing integrations with other systems for years.

Would you like to bring your website to the next level?

Yes, wire up my website!

Jun 08 2015
Jun 08

Drupal has a particular way of doing things, which is sometimes not to the taste of everybody. This can lead to a misplaced feeling that it is weird or difficult. However, the Drupal way comes from years of developed good practice, and is backed by tens of thousands of developers' knowledge and experience.

Doing things the Drupal way means working with the framework, and not at odds with it. Doing it the Drupal way saves headaches down the line. It means coding to standards, which leaves your code in a state where it can be read and understood after the project has gone live. It makes it maintainable. It means thinking about the next developer who has to work with the code and making sure that they can figure out what is going on before making changes.

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live”
― John Woods

Use the Framework

Drupal is modular. It makes no assumptions about how you want your site to function. Therefore, it is extremely versatile. The correct approach when doing a site build is to get most of the way there with contributed modules and only when it comes to tweaks and minor changes do you crank up your editor and write custom code.

This distributes the burden of security maintenance because module maintainers will be upgrading and patching their modules for you.

When you are presented with a new challenge, remember: there's probably a module for that.

Make things configurable

One of Drupal's great strengths is its configurability. The Drupal way is to enhance that strength. When writing your own modules, allow the user to configure them, rather than hard-coding settings into them. Drupal provides a solid API just for this. Following on from this, think about making your modules generic. In this way you may be able to reuse them from site to site and save yourself work. You could even contribute the module back to drupal.org and give back to the community that has built such an fantastic tool. Here's how much Annertech has contributed to the Drupal Community.

Override, don't hack

Often it can seem easier to developers unfamiliar with the framework to dive into existing published code and make changes to it to get the desired result. The result of this approach is a site that cannot be upgraded in the face of security patches and new releases. Core and most modules provide hooks (functions that you can use) to hook into the processing workflow and make your customisations in a controlled manner. By respecting published code and using hooks, keeping your custom code separate, you can keep your site safely upgradeable and all your custom code in an obvious place, for easier maintenance.

Use templates for presentation only

Novice developers will almost certainly delve into the theme system as it feels like a natural progression to move from writing CSS to making simple modifications to templates. The golden rule when working with templates is this: templates are for presentation, not logic. A template should contain mostly HTML, with at most some conditional print statements. A template that contains business logic is wrong. Logic belongs in a module, or at a pinch in template.php, if related to presentation. A sure sign that a developer is inexperienced is when you find more PHP than HTML in template files, and lots of them.

Keep Modules Atomic

It always seems easy to hurl all your site's logic into a single module. However, it is worth the effort to separate out discrete chunks of code into different, themed modules. Maybe there's one for dealing with forms. Maybe there's one for listings. Maybe there's one for dealing with integration with a CRM. Keeping your modules separate makes it easier to find your code when you need to make changes, and allows you to turn off parts when necessary (e.g. if you do not want to send test data to an external application).

Never, ever, put PHP in the database.

Seriously. Just don't.

There is a module which will allow you to enter PHP directly into an input field through the admin interface. This is a huge security risk, and can result in massive problems. A missing curly brace can take down your entire site. A deprecated function in the database can destroy your site if you upgrade PHP without finding it. You cannot search your codebase for code in the database. It is invisible to you and will cause you massive problems. You cannot put this PHP into version control. All in all, it may well be the single worst thing you can do to your site.

Views Vs SQL

Views is amazing. It allows you to quickly build really complex queries and then format them in an astonishing number of ways for display on a page, and all without writing any code. Sometimes, however, Views can reach its limits, far-reaching as they may be. However, any query built on Views can easily be changed, tweaked, rebuilt and remoulded to another purpose.

SQL queries, on the other hand, can be faster, as they are talking directly to the database, and can do anything the language will allow, but do nothing about presentation or building an output to display on the page. They cannot be edited through the UI and are often more difficult to understand.

The Drupal way would be to use Views for any user-viewed listing, and resort to SQL for only the very simple, back-end queries, for speed, or the extremely complex queries that Views cannot handle.

Learn to use theme()

The theme() function allows a developer to specify markup in a module, but allows the themer to override that markup without hacking the module. If you are putting HTML markup into your code, it should be in a theme function, and called via the theme() function.

Use the Drupal API

A lot of thought has gone into Drupal. Knowing PHP is not enough to build a good site. You need to get to grips with the API and use it. Leverage entities. Figure out how to use the entity_metadata_wrappers. Wise up about when to load entities to get the data you need. Embrace the form API and make your forms dynamic and reliable. The API is there for excellent reasons and should not be ignored.

Don't forget about security

There are plenty of articles on writing secure code. The thing to remember is: never forget about the need for security. Drupal provides excellent filters for sanitizing user input on display, such as check_plain, filter_xss, etc. They will save your site.

Structure Your Content

One thing that is sure to bite you down the line is content that is all jumbled together into a single body field. Drupal provides a user interface and solid field API for modelling complex data structures in a simple way. This makes responsive sites, data re-use, publishing on different platforms etc. all possible.

Look at the Field Collection and Paragraphs modules, all the Media modules and embrace sturctured, rich media experiences.

A WYSIWYG is great for editors, but make sure that it can only do what is needed, not everything. Having said that, there are noises about meeting half way between stucture and freeform content. See this rather informative presentation from DrupalCon LA - the Battle for the Body Field.

Would you like your site built the Drupal Way?

We'd love to hear from you!

May 14 2015
May 14

At DrupalconLA, I had the opportunity to go to an Open Front End Forum, wherein people chatted about the state of the front end. It was good fun, and the moderator did a good job of keeping the conversation flowing.

First question: "Where is the line that separates front end from back end?"

There was some disagreement on that. There is a line, there is no line, it's a permeable line... Going on to explore what defined front end or backend, people cited tasks and tools like PHP, HTML/CSS/JS, the browser, Photoshop, in favour of one argument or another.

Next question: Then he asked, "What do you call yourself?"

A front end dev? A themer? One chap claimed 'I do front end development', which was cited as a rather nice way to think about it as he was not defining himself, but rather just describing what he did.

Similarly, I was thinking: "I make websites".

Front end frameworks were also discussed at length. Angular, the cool kid on the block, kept surfacing and re-surfacing, as it seems to often be considered 'easier'. Interestingly, nobody cited any of the negatives of using front-end frameworks that had been talked about the previous day, such as the fact that you lose all the good stuff baked into Drupal, e.g. you need to worry about form API stuff, user password reset, SEO etc.

But everyone agreed that they love the shiny toys. There was a discussion around 'what if a framework was baked into Drupal Core?'. "Ah it'll never happen" seemed to be the consensus. Note: Backbone and Underscore were actually added to Drupal Core in 2013!

There was talk about front end people resenting or resisting the increasing complexity and 'back-ended-ness' of the front end, and some complaining about having to write PHP.

A couple of brave souls actually stood up and asked "Why can't we do both? I do both."

My thoughts

I've been making websites since 1998, hand writing HTML and styles. There was no front end and back end. There was just a website. Now, I still make websites. I let Drupal do the hard work, and then I massage it to fullfil my clients' dreams.

What I was hearing from several people in the room was that they had found their niche and did not want to leave it. They did not want to learn anything new, with the possible exception of Angular, the shiny new toy. This can't be good in such a fast-moving industry.

Back in the day, I learned HTML to make my first page. I learned CSS to make it sparkle. I learned JS to make it dance. I learned to love JS through the cross-browser magic provided by learning jQuery's API. I learned about and how to use a few CMSs and built sites with them. I learned and wrote SQL like a badass. I busted a Java groove and rocked some servlets. I learned Drupal and quickly tried to forget some previous CMS horror-shows. I learned some PHP. I learned how to modify templates and override preprocess functions. I learned how not to write a module. I learned how to write a module. I learned SASS. I learned Git.

It just keeps on going. I love to learn.

A home truth that just keeps coming back to us at Annertech is this: "If you are not embarrassed about the code you wrote 6 months ago, you are not learning fast enough."

To "front-enders" afraid of the back-end, and "back-enders" afraid of the front-end, I say to you: You work with computers. If you can handle Javascript, you can do PHP. If you managed to build a site through manually crafting the HTML, you can manage CSS. If you can manage CSS, it's a small step to SASS and from there we're back to PHP. It's all the same delicious burrito with different salsas.

I feel that one big exception is in design, and specifically graphic design, which is a very magical skill, and doesn't immediately follow from code. But even those blessed with warlock-like Photoshop chops need to know how their design can be implemented, or else they are dreaming up a whole world of hurt.

By all means, find a preferred area of expertise and hone that craft, but know how all the other areas work. Each layer of the technology stack for a modern web site impacts on the construction, architecture and performance of the others, so it is imperative to understand the knock on effects of your decisions.

The take-aways from all of this are simple:

  • keep learning, all the time,
  • living in a silo leads to unhappiness all round,
  • lastly, commit - to your choice of career, to amazing websites and to always using version control!

Contact us when you are ready to accept the help that Annertech can give to your project. We build award-winning websites.

Feb 26 2015
Feb 26

In yesterday's installment of this series we looked at adding some wow factor through the aesthetics of a project. Today's we'll look at:

Creating Wow - Service

Wowing your clients is not solely about the end product. The delivery of that product and its ongoing service and maintenance are just as important for the ongoing happiness of the client and therefore the bottom line.


I work principally on providing support and ongoing agile development for existing sites. When you are asked to work on an issue, if you can turn that ticket around faster than expected, that will impress the client. Similarly, if there is an emergency, regardless of the cause/nature, if you can respond in a fast and effective manner, your client will be happy.

I find that quick, simple responses go a long way, even if you can't work on the issue right now. Simply tell your client when you will attend to it, and crucially, follow up on your promise and deliver. Nobody wants to hear "oh, sorry, I didn't get that done because I was doing work for someone else', but people do live in the real world. If you can manage expectations and make promises you can and do keep, then that will go a long way to wowing your client with solid, reliable service.

Security updates are an issue that causes many site owners alarm. People new to owning a website will be unaware of the need for updates, or the transient and continuously evolving nature of software, but it is a reality which must be embraced. You can turn this into a way to improve your service delivery by scheduling for security updates. Security advisory notices come out on a Wednesday evening, so they are easy to take in to account.

Similarly, API changes, typically in 3rd party applications and services is something to be aware of. You can be sure your client has not thought about Google Maps changing its API. They only know that their map has stopped working. If you, however, can warn them before the event and have a solution ready, you will be the hero of the hour.

Proactivity is king!

New Business

New business requires a slightly different approach. Obviously, with all the talk of wow, you can't ignore budgetary constraints, nor give away your shirt. Everyone has heard stories in the news of IT projects going wildly over budget and taking multiples of the expected timeframe. If you can deliver your project on time and on budget, that is wow factor right there. Couple that with consistent, solid, positive communication throughout the design and build process and you will have a client who wants to work with you again.

The next installment (to be published tomorrow) looks back at the various tactics for impressing your clients and offers some concrete ideas for transforming the ordinary into something special!

If you want to discuss Annertech helping you build an award-winning website, please feel free to contact us by phone on 01 524 0312, by email at [email protected], or using our contact form.

Feb 23 2015
Feb 23

Creating 'wow' is something we all need to strive for. It's that extra element of pleasure that someone derives from something we've done. The key to wow is in its unexpected nature. It's in the unexpected pleasure from stylish subtleties in a design that leaves you going "nice!". It's in those clever extra features a user discovers after a while using a site, which they now realise they just love. It's about delivering that little bit more.

This is part 1 of a 5 part series.

Know Your Audience

The audience matters when thinking about what will wow someone. What strikes a user as amazing will surely be different to a hardcore back-end developer. The CEO will be impressed by quality of service, speed of delivery and value for money. The site editor will be far more interested in a performant site with a slick editor experience. You need to think about who you want to impress in order to make it happen.

Why wow?

But 'hold on', you may be thinking, 'This doesn't sound very Agile', 'What about doing just enough?' and 'How can we do that on a fixed price contract?'. The thing is that making people go wow actually makes good business sense. A happy client is more likely to work with you again and recommend you to their friends. Happy users make for successful sites, which in turn makes happy clients. What we need to do is build the wow factor, the same way you build quality, into your core processes. Make it part of what you do and who you are.

Wow, how?

So the question remains: how can you bring some wow to the table? When approaching a project, you need to keep the context of the budget in mind at all times. Within that context, talk about features that will delight your prospective client during the sales pitch. And once you've got the job, think about what will enable a slick experience or facilitate something cool as early as site architecture, all through the design process and site build and styling. Choices in one area will affect the ability of others to wow, and you will need to trade off one against another in order to meet your budget constraints.

3 Attack Vectors

You've got three main avenues for wowing your clients.
- Technical
- Aesthetic
- Service

Tune in tomorrow for Part 2: Technical Wow!

If you want to discuss Annertech helping you build an award-winning website, please feel free to contact us by phone on 01 524 0312, by email at [email protected], or using our contact form.

Feb 06 2015
Feb 06

Last month I wrote about why we care about responsive websites, and why you should too. This month I'm going to brush the surface of how one might achieve such a goal.

Responsive Buzzword Bingo

I'm not about to go knee-deep into the semantics of the various jargon words surrounding this topic and their pros and cons, but here are broad descriptions of some of the approaches.

A responsive site uses fluid grids and fluid images to resize according to screen width. A fluid grid or image does not have a fixed width, but rather it expands to fill the available space. This is backed up by media queries to change the style where needed at certain widths, or "breakpoints". A good way of thinking about a breakpoint is this: you need a breakpoint (i.e. a change in styles) at the width at which your layout starts to look broken.

An adaptive approach chooses specific fixed widths, so you get one layout for mobile and one for desktop and a fixed width for each of those. An adaptive theme does not typically utilise fluid images or grids.

Mobile-first is a design philosophy based upon the assumption that the smallest screen should be catered for first and the pages built up as screen size increases. This is the polar opposite of the traditional 'build it for my desktop and maybe think about mobile later' approach.

Mobile websites are another alternative. This is a separate site, serving content at a separate URL.

At Annertech, we would choose to build a responsive, mobile-first site on any new build.

Tips for Responsive success

1. Think about interactions.

A web site is not a static image. The designers of a website need to plan for how a user interacts with an application, but also for how a site interacts with the device. How should the various elements on the page sit on a portrait iPad? What about a monstrous home-cinema screen? Should they be stacked, or sit side-by-side? What should be displayed on a phone? They need to think through tasks and workflows and how the site works. How will the user perform tasks? Where will they be doing it? Does the action button need to be sized for and accessible to a thumb?

2. Optimize images

Fluid images are great, but downloading huge images on mobile sucks. A fluid image carries the same byte-size (i.e. the same amount of data has to be downloaded) whether presented on a tiny phone or a huge monitor. Downloading a one megabyte image over broadband might not make you blink, but doing the same over a tenuous edge network on an expensive per-megabyte data plan will make you think twice about accessing a site. Until it becomes commonplace to be able to send different images sizes to different devices, we need to optimise both our use of images and the images themselves. A big hi-resolution background image might look great on desktop, but it is just a pain to download and may never be seen on mobile. So at design time, ask yourself: do I really need this? In Drupal, we have the benefit of image styles to set our image sizes. Use these to make sure we are only serving images as large as they need to be for their use-case.

3. Design in the browser

When designing, a static design comp (i.e. a mock up of a page) can get you started, but it can account for neither all the differing screen sizes nor interactions between user and app. Whilst Photoshop can get your concepts down, there comes a time to leave it behind. Design in the browser is invaluable for creating out responsive layouts. Using this approach, we build interactive prototypes that you can use to get a real feel for how your finished website will work on different devices.

4. Use a CSS Preprocessor

If you have not embraced the CSS preprocessor revolution yet, now's the time to get on board. CSS preprocessors allow a developer to write far more efficient, readable and understandable code, which is compiled down to normal CSS for the browser to understand. It dramatically increases your effectiveness when styling a website. At Annertech, we use the power of SASS and Compass to solve amazingly complex problems efficiently and effectively.

5. Make it fast

Don't forget about performance. Ever. From the start of your mobile-first design, think about your goal of delivering the content your users want as fast as possible. Do you need that background image. Do you, in fact, need any images? What about that web-font? Can you use Georgia instead? Can your design embrace consistency across the site, rather than adding new design elements on every page? It's a wise approach to set a 'performance budget' when starting a project. This allows you to gauge just how much impact every additional request or asset or feature is going to have on the speed of your site. Always ask yourself: do I really need this? Remember, people don't like to wait! Have a look at this presentation from DrupalCon Amsterdam, where they talk about getting a page to a phone in under 1000 milliseconds.

So that's it - 5 tips to keep in mind when creating a responsive website. 

If you want to discuss Annertech helping you build an award-winning website, please feel free to contact us by phone on 01 524 0312, by email at [email protected], or using our contact form.

Jan 28 2015
Jan 28

"OMG! You've got a responsive website!"

Update: Part 2 of this series: 5 Tips for a Responsive Website is now available.

Once something to brag about, this is now old news. Of course it's responsive - that's standard practice now, right? Unless your site is not responsive, in which case, you are probably losing visitors and money. And now that Google has started adding "mobile friendly" tags to its search results, you can be sure it'll soon be an SEO bonus to have a responsive website.

The various resources coming up on my searches can't seem to agree on exactly what percentage of internet users are mobile internet users, but they do all agree on this: mobile is big, mobile is growing and most users don't use one device exclusively. This means that the same people are visiting the same sites on different screen sizes and expect a very good user experience each time.

Think about a typical day.

Your alarm sounds and you pick up your phone to turn it off. Seeing as you have it in your hand, you have a look to see what's happened in the Twitterverse overnight. At breakfast, you lazily cruise some of your favourite sites on your tablet. On the bus, you're back on your phone, reserving cinema tickets for tonight and finishing off some of the tasty articles you scanned over breakfast. Now in work, you've got your big desktop monitor, doing some research. Tired of flicking between browser tabs, you arrange your windows with three browser windows side-by-side. Home-time comes and you're back on your phone, in a queue, whilst waiting to be served some fries before the cinema. You hit home just in time to stick the phone on charge before its tired battery dies altogether.

Imagine the annoyance if you hit a site that does not take account of your device, that does not adapt to your view. You're busy: you've probably got other things to do. There's usually another site that does what you want. If it's responsive, you'll probably end up doing your business there.

This scenario is not too far-fetched. Modern life is connected. People are on the go whilst they are on the go, and two things they really dislike are having to think whilst doing something else, and having to wait whilst waiting. In much of our typical day, there's more than one thing going on: breakfast and surfing, Twitter and queueing for fries, travelling and booking tickets. The attention of the user in each case is split. They are distracted, and they are not happy if they have to struggle to use their sausage fingers to navigate tiny icons and then stare at a blank screen whilst the page fails to load.

Be nice to your users: you want them to come back and to use your service. In order for that to happen they have to feel good about doing it. A poor mobile experience is not going to make that happen.

People often worry that responsive sites are more expensive. They don't have to be, once it starts at the design stage. A design can facilitate it or hinder it, and it's going to impact on both the budget and the bottom line.

Most of my work lies in supporting existing sites. I have actually found it easier to maintain responsive sites than fixed width sites, because of this: when adding new features, typically a responsive site is built in such a way that the new feature will just work. This is because both the designer and the developer have understood how each element interacts with its neighbours and have thought about how that interaction will play out over different screen widths. Fixed width or partially adaptive sites inevitably cause layout problems, as they facilitate lazy CSS. You don't have to be a CSS ninja to fix a width, but you really have to think when creating a fluid grid with breakpoints.

Who needs a responsive site? 

Everyone. Users need to use them because it makes surfing on a mobile device suck less. Site owners need to own them because it makes users happy and increases conversions. If you are thinking of getting a site built, make sure it's responsive. If your agency is not providing responsiveness, ask yourself: are these guys cowboys? If you plough ahead and get a non-responsive site, it will lose you money and you will still inevitably come to ask the dreaded question: "Quick one for you - can you make my site responsive?".

Have a look at the analytics for your own site. All those users you thought would never move away from IE6? They're now using ipads.

Mobile is real. But what is it? 

At its simplest, a responsive site is one that changes depending on the screen width of the viewing device. This means that you don't have to pinch-zoom to read the main content on a page, and you don't have to struggle to deal with fly-out menus or wonder how on earth you're going to navigate the site that relies on 'hovering' over the main navigation to activate the sub-menus.

You can go further down the rabbit hole and talk about adapting the content depending on device or location, or talk about serving different images dependent upon device or connection speed, but the basic responsive site is just an adjustment of presentation to better suit the viewing tool.

If you're still not convinced, have a look at this presentation from Luke Wroblewski at Drupalcon Denver. It is well worth kicking back and enjoying this excellent talk on all things mobile and web.

So, only one question remains:

Do you want a responsive site?

Yes, I want a responsive site!

Apr 29 2014
Apr 29

Drupal Dev Days this year found its way back to the location of Drupalcon 2008 - Szeged, Hungary. A particularly picturesque city, Szeged made a wonderful location for a great conference, and Annertech was there to enjoy it all.

The conference itself was a full blown marathon, with code sprints going on all week, and well into each night, and a full three days of workshops, BOFs and sessions. It was not one to miss.

There was obviously a Drupal 8 theme at Dev Days, not least because the code sprints were trying to eliminate all the beta blockers from the issue queues. Solid sessions on the new Entity API and its integration with the new Field API explained how they are basically now one and the same. Translation, authentication, configuration management and performance in D8 were all explored.

A rather interesting talk was given by Florian Loretan, of Wunderkraut fame. He was asking the question of when Drupal 8 will be 'real', or to put it another way, what does it take for people to use it on real projects? Out of the box, Drupal 8 is pretty powerful, and even now, you can find sites built upon it. Florian suggested that, currently, the system is suitable for personal sites, blogs and brochure sites. As D8 matures and more contrib modules become available for it, so its capabilities will grow exponentially. For example, rumour has it that Drupal Commerce will have a beta release when Drupal 8.0 is released, and that will immediately open a huge range of possibilities. Drupal 8's time is coming. For real!

A real treat was a re-run of a workshop from Drupalcon Prague. I really think that workshops are the way to go - they can be far more engaging than all but the most lively speakers, and the potential for learning is far greater! In this case, the Caching Deep Dive made a comeback, and I have to say it was really excellent. Campbell Vertesi took us through all the server side caching layers available in a high performance Drupal stack, explaining in an eloquent and entertaining style the mission of each component - APC, Memcache, Varnish - their differences, and how to make them sing for you.

Some other takeaways included
- a presentation by the guys at Happy Culture on caring for the 'editor experience'.
- a demonstration of a brand new front end testing tool by Timm Jansen - siteeffect.io, which is really brimming with potential and we are eagerly awaiting its full release.
- a great rundown by Klaus Purer on security, attack vectors and how to keep the enemy at bay.

But of course, Dev Days was not all work. Nights were filled by the sounds of happy Drupal developers having fun around beautiful Szeged, not least at the Friday night party, co-hosted by Freistilbox and Aberdeen Cloud, which even came with a great progressive jazz soundscape performance!

The conference was a huge success, and congratulations are due to all the organisers. The only thing that remains to say is: roll on Amsterdam!

Sep 20 2011
Sep 20

A few weeks ago the entire Annertech team left from their respective corners of Ireland to attend DrupalCon London 2011.

I flew Cork to Heathrow and after some initial London transportation difficulties (protip: buses are never direct) I found myself safe in Croydon, wandering around under the always reassuring helium filled Druplicon.


During the conference itself, I found myself running around between the sessions in the main conference building, the core conversation room and the offices hosting the Birds of a Feather.

I particularly enjoyed the core conversations. I found them to be very accessible and it was interesting to hear people's visions for the future direction of Drupal. The build up to the conference was marked with a lot of interesting discussions on some of the challenges facing Drupal. During the conference however, many of these issues were worked out through conversation, collaboration and compromise. The core conversations reflected this. People with different interests and priorities all working together to create useful, robust and beautiful software.

I also really enjoyed the BOFs (Birds of a Feather = a small group having an informal discussion). I attended a half-dozen of these discussions on different aspects of front-end development. BOFs are a great way to have a focused chat about areas of shared interest. If you have not participated in a BOF previously you should definitely add it to your to-do list for the next DrupalCon.

Stella, Alan and I all participated in the code sprint on Friday. I worked with Alan on some of the front-end focused issues for Drupal 8 (in particular some HTML 5 issues). Stella worked on upgrading some of her modules to Drupal 7 (FAQ module now has an RC release!).


In the same way that Drupal is as much a community as it is code, DrupalCon is as much about socializing as it is about the sessions.

It is not everyday that you get to hang out with people who are passionately interested in all the various aspects of web design and development. As such, I always try to take maximum advantage of the opportunity to talk script loading strategy during lunch, debate the render API at dinner and chat browser reflows over drinks.

I might be accused of a (tiny) bit of bias, but my social highlight was the DrupalCon pub/table/trivia (delete as appropriate) quiz organised by Drupal Ireland. All at Annertech were involved in putting it together. The table quiz was a refreshingly analogue event with the use of all new-fangled, will-never-catch-on digital devices banned. Unfortunately, the analogue style meant that I had to score the various teams with nothing but pen and paper. Stella, Dermot and myself were the markers for the evening. We may have been a bit rusty for the first round but we progressively modified and improved our hand-crafted algorithm. By the end we were all pretty exhausted, but our table quiz marking skills were much improved!


So, DrupalCon London: one or two buses may have broken down, the occasional lunch time may have been a bit hectic, the odd wifi connection my have timed-out, but we would not have had it any other way. Big thanks to all involved in putting on a great conference.

See you in Denver 2012!

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web