Subscribe via RSS

And The Drum Network Awards nomination goes to…

It’s been all smiles over at Positive Studio as we celebrate our work being recognised by the prestigious Drum Network Awards!

We’re proud that our work with The Children’s Society re-developing their blog has been nominated for both Charity Campaign/Strategy of the Year and Social Media Campaign/Strategy of the Year. Meanwhile Send a Cow’s Lessons from Africa hub for teachers is also up for Charity Campaign/Strategy of the Year.

We’re happy to be recognised by The Drum as industry leaders alongside some of the best creative talent out there. We focus on delivering effective solutions for our clients and these nominations demonstrate how hard our team works to achieve results with our clients.

Check out all The Drum Network nominations here

Winners will be announced on Thursday 3rd December. Fingers crossed!

posted by

Pick 'n' mix: a guide to technology choices for charities

Which technology should you be backing and how should you go about it? This is a common problem for charities. Describing your organisational challenges might come easily, but pinpointing which technology provides the best, most cost-effective solution is a different matter. The reality is there’s no single right solution or approach when it comes to choosing your digital technology. So where do you start?

That’s where our new report comes in: Pick ’n’ Mix: a guide to technology choices for charities, developed with CharityComms.

We surveyed 74 digital leads working in the charity sector on the technology they use and the challenges they face. Then we took these findings to a team of digital experts from The British Heart Foundation, Diabetes UK, The Children’s Society, Arthritis Research UK and more to share case studies and recommendations for choosing digital technology. Our experts identified six recommendations for choosing digital technology.

What’s clear throughout the report is that if your organisations are to get the most from their technology, digital teams must be more involved in these decisions. They are often in the strongest position to demonstrate how your organisation can use technology to meet its organisational objectives.

This guide covers all this and more, including:

  • Planning a digital technology project
  • Personalising the supporter experience
  • Mapping customer journeys
  • Digital’s potential to use data
  • Saving time and money through documentation

Download Pick ‘n’ Mix: a guide to technology choices for charities and share your thoughts on Twitter @PositiveBristol #TechChoices.

posted by

Three lessons for engaging your fundraisers

When someone signs up to fundraise for your event, it’s clear your campaign has caught their eye. But if the campaign centres on a personal challenge, such as The Children’s Society Tough n Buff campaign, keeping them engaged over a period of time can prove a bigger hurdle.

Tough n Buff is a 30 day fitness challenge where participants take part in tasks such as squat challenges and burpee time trials and compete against others, whilst being sponsored to get fit. One of the key aims of this campaign was to develop a platform that could be re-used and that would keep fundraisers engaged throughout the one-month Tough n Buff process. We created a Drupal module for the new platform and used JustGiving’s APIs. We learnt a lot while developing the platform, and as any charity can use JustGiving’s APIs, we thought we’d share our top three lessons for keeping your fundraisers engaged:

1. Simple is best

Presenting information and data to your fundraisers in a way that’s clear and easy-to-use is the Holy Grail. We wanted to make it simple for fundraisers to access all the information they need in one place. We’re working to improve the sign-up and login process on the Drupal module in time for the Tough n Buff campaign’s second release in January.

2. There’s nothing like a bit of competition

It’s important to keep your supporters motivated and creating a little competition can work well! We created leaderboards for fundraisers to see how they’re faring against others, or to challenge their friends to take part. All of this information appears on the fundraisers’ own personal campaign profile. We’re still improving the ability for fundraisers to share the campaign and to build fundraising teams as we know that this functionality is important to encourage sponsorship.

3. Celebrate success

One of the keys to engaging your fundraisers long-term is to show you’re with them every step of the way. This means tracking their progress and thanking them. We made it easy for fundraisers to see who is taking part, how much each supporter has raised and how they’ve shared the campaign – this data could then be used to lead the campaign communications, personalised emails and to help The Children’s Society thank their fundraisers.

Sarah Espiner, digital fundraising manager at The Children’s Society, explains how they’re using the Drupal module for Tough n Buff: “The Tough n Buff site has been built especially to provide a really easy sign-up process where, using your Facebook log-in, users can automatically set up a JustGiving page in support of their fundraising, which includes a Tough n Buff profile page to show you how many exercises they should be doing on a certain day. At The Children’s Society we’ve tried to make it as simple as possible for the supporter, knowing that they’re likely to be short on time.

“We ran competitions on social media to spark conversations with our Tough n Buff participants, and keep them involved and entertained. We also encouraged fitness bloggers to get involved. We kept the tone of our engagement really light throughout and we gave supporters the option of whether they wanted to receive daily or weekly email reminders of their fitness goals for that day. Our emails had a great response throughout and we had some participants raise really high sums of money to support us!”

Find out more about how we're making Drupal work for The Children's Society.

This blog first appeared on the JustGiving blog on 27/10/2015.

posted by

Five reasons you’ll love Drupal 8

This week (19th November) the Drupal community announced the release of Drupal 8. With more than 200 new features, this is the kind of news that gets community regulars like me very excited indeed.

If you’ve just invested in a new Drupal 7 site don’t panic – it will take time, tweaks and a few more releases before it’ll be worth migrating, so right now we still think Drupal 7 is the best content management system that’s out there; we won’t be recommending a Drupal 8 build for our clients for quite some time yet.

That said, anyone using Drupal or thinking about switching should know the possibilities that lay ahead. So here’s our run-down of the top five reasons we love Drupal 8, and we think you will too…

1. More fields in core than ever before: To those already using Drupal the importance of this development does not need explaining. To those who are discovering it for the first time, it basically means that Drupal 8 is a more complete ‘out-of-the-box’ product than its predecessors. In the past Drupal has relied on modules to fix elements that aren’t already there. But with Drupal 8 the core CMS now includes fields such as telephone, link, image, email and even views (the ability to easily list types of content e.g. blogs or new products). This is good news for users but also for contributors, who can now focus on improving Drupal rather than fixing holes.

2. Mobile editing is here! Drupal 8 offers users a first-class responsive admin experience. It’s mobile first, allowing you to post from a tablet while at a conference just as easily as you can on a desktop. There’s also a quick editor option available across the system to make small changes easily, wherever and whenever you want.

3. Better user experience: With additions to the core you can get set up faster, and there is now a live guide to help you when using the CMS so you don’t have to leave it to look on the help page. They’ve also made editing simpler with in-place editing of content – no need to use the full-edit form – and it’s much simpler to migrate from earlier versions.

4. Improved performance: In some cases Drupal 8 is twice as fast as Drupal 7. It’s built for developing enterprise level websites and it’s now easier than before to set up multilingual sites to help you reach a global audience.

5. Still Drupal: While a lot has changed, what we probably love best is that it remains the product of a global community who genuinely care about the product and the people that use it. Why not join us?

Check out how we’re making Drupal work for The Children’s Society.

posted by

Do Different Relay for The Guardian and MAA

Last week we spent a day doing differently for the Marketing Agency Awards #DoDifferent relay and the entire day has been caught in a short film now showcasing on The Guardian website.

Taking the theme seriously we sent Ringo, our Creative Strategist, and Project Manager Nick off to spend the day carrying out agency business while relaying across the beautiful city of Bristol, where our studio is based.

Sounds simple enough? There was a twist. Ringo and Nick had to spend the day travelling on a tandem bike and hit all the sights of (very hilly) Bristol to celebrate becoming the first UK city to win the European Green Capital Award.

The guys had to think on their feet (literally) as they attempted to collect stories from sustainability experts across Bristol – including Sustrans Cycle Network, TriodosUK and Bristol 2015. We will be featuring these #SustainableStories in detail on our blog throughout October and the the plan is to feature them as part of an online resource we're developing to help young people learn about sustainability.

For us, the day was all about challenging the way agencies work and seeing what could be achieved when we take a different approach to our work. Ringo and Nick had to spend a day away from their beloved technology, warm studio and coffee on tap, but they came back inspired by the stories they’d heard (and a little bit fitter!).

We can’t wait to share these stories with you, just look out here on our blog or for #SustainableStories @PositiveBristol

Check out the short film of Nick and Ringo’s big day out in Bristol (as we’re calling it!) now on The Guardian website.

posted by

Going headless with Drupal

Headless Drupal - An introduction from Positive.

head•less (hĕdˈlĭs)

adj. Formed without a head

adj. Decapitated.


Headless Drupal is a way of utilising Drupal to build solutions where the user does not directly interact with Drupal.  Examples include building a front end with a JavaScript framework, rather than the Drupal theme layer, or building a data store for an iOS app.

In this article I’ll show you how to get started building a REST-full back end, and how to approach building an HTML front end app to this.

I’ll give some ideas about how you could use Drupal as a part of a S.O.A. (Service Oriented Architecture). I’ll review some of the pitfalls of taking the headless Drupal route, and some ways to mitigate them.

Finally I’ll give some examples of headless Drupal in the wild, and where things might be going with Drupal 8.


How do you go about ‘Headless Drupal’?

The best way to start is with the services module. Out of the box this gives you the tools to create a REST endpoint to your Drupal site.

REST – representational state transfer – is a standard way to interact with systems over HTTP. It uses the HTTP verbs (GET, POST, PUT, DELETE) against resources.

So for example you POST to /node to create a node, and you GET from /node/1 to read a node.

The core services module provides a REST API for nodes, comments, files, taxonomies, users and system resources.

On a site with this enabled, lets look at interacting with it via REST using an app called postman (a chrome app). I could have used curl, or written code here, but I like to test API’s like this before writing any code.

On the Drupal side we have our api located at ‘/api’ on the site:


Headless drupal code example


And the system resource is enabled


Headless drupal code example


We can then call the POST method to the system/connect method.


Headless drupal code example


You’ll see a couple of important things from that screenshot. The first being you have to set the content type (its important). The second that it is really that easy!

This endpoint is a useful one, as it tells you who you are.

The information returned here is important too – that ‘sessid‘ and ‘session_name‘ are used in the authentication cookie.  Lets have a look at another method key to authentication before moving on to something more complex.

The services module has a ‘Cross Site Request Forgery’ security measure through using a token.

‘Cross site request forgery’ is basically session jacking. By taking your session tokens with a click, an attacker is getting an authenticated session as though they were actually you, and will be able to do all the things your user can do.

Without this token – the session isn’t valid (and it isn’t kept in the session so can’t be highjacked)


Headless drupal code example


We now have the information to log in as an authenticated user.

Lets step through what that looks like, logging in, creating a node and requesting that newly created node.

1)   post to /user/login


Headless drupal code example


Here we post the username / password to the user/login.json end point, and it returns the data needed to continue our authenticated session.

2)   By using that new token and session we can call system/connect to check our identity. You can see it doesn’t return the token – its not part of the session, hence the protection.


Headless drupal code example


3)   No we know we are authenticated – lets create a node, and read it back.

To do this, we post to /api/node


Headless drupal code example


And as easy as that we’ve created content.


Headless drupal code example


Remember – this is REST, so to read it back, we do a GET against the resource.

And if we want to delete it, it’s just a DELETE request.


Headless drupal code example


With the core services module – regular operations such as authenticating a user, creating and reading content are quite easy.

Services has a very healthy ecosystem of companion modules, services views, and services entity are key, and with them plus the core, you’ll be able to build 95% of what you want.

The services module provides a programming API, with this you can add your own resources and expose them as a service via a custom module.

This combination means you can create a very rich, functional backend for any front end.


What are the advantages?

So now we know how to create the back end to the app. Let’s look at the advantages of doing things this way.

There is definitely a ‘cool factor’ to headless Drupal at the moment, and whilst it’s great to do cool things, it shouldn’t be the only reason you do something.


Front End Ops.

Just as Dev-Ops has revolutionised the data centre, front-end ops is beginning to do the same for front-end web development.

We’re seeing the emergence of dependency managers like Nodejs’s npm and bower . There are  JavaScript task runners like Grunt.js and Gulp for process automation..

There are mature Frontend application frameworks like Angular and the continued evolution of front-end responsive frameworks.

We used Zurbs’ Foundation Foundation for Apps  (FFA) to build a headless site for The Childrens’ Society.

Zurb claim this as ‘The first front-end framework created for developing fully responsive web apps’

But the clothes don’t maketh the man…

Some clever SCSS mixins, UI components and a nifty grid aren’t enough to build a compelling web application experience. This is why Angular JS is wrapped up with FFA,  providing some easy to use helpers like Motion UI and YAML front-matter routing.

De-coupled means just that. Separation. We could build the SPA front-end without reliance on the backend functionality what so ever.

This led to what you could truly call an agile approach to creating the frontend of the app.  I’ll outline how we approached it. We found it was a remarkably freeing departure from the traditional Drupal theming process.

1 ) Using flat .html files with YAML front-matter blocks (provided by Foundation for apps) we created our ‘pages’ within our SPA


2) We could then write a controller for this route to use, and provide this to the route via the front-matter block again.


3) An Angular service was then written using the $resource factory in the ngResource module (including this in our application dependencies) to consume a mocked up json file that could be served locally for testing with the intent of being swapped out for the finished api service calls mentioned earlier.

4) We then use Angular’s dependency injection to inject this service into our controller and use promises to retrieve out content from the service.

Foundation for apps uses gulp for task running which made our workflow nice an easy. Any SASS compiling, auto-prefixing, concatenation and minification where triggered when watched directory’s and files where changed, meaning a short wait and livereload firing and our finished product was in the browser ready to view.

This modular approach front-end developing goes hand in hand with the modular manner of modern dependency managers . Over the course of development we found instances where we needed symlinks being created at build time, or using browser-sync for device testing, even regression testing with wraith. All of which where resolved by installing plugins when we found requirement for them.

In short we found that any time invested into the set up and customisation of front end tooling and its repeatability of tasks and processes was just that. An investment, which we saw a great return on.


Deep integrations.

You can now view the resources in your Drupal site as a toolbox you can reuse across an organisation, keeping the same first class CMS experience.  Any application that can ‘talk’ REST can integrate with you now. There are almost no limits , but here’s a few ideas .

·      Pull information from a profile on the intranet to your staff address book

·      When a new starter joins, automatically create them a listing in the intranet.

·      Pull recommended content from one site to another.


Using an industry standard CMS for the data store of an app.

One of the biggest and best use cases for headless Drupal is to use it as the backend of an app (either iOS or android), where they handle the entire rendering for the app.

The Drupal community provides MASt  - the mobile app services toolkit

An app back end module to kick start this development and an iOS SDK and a reference application that works with the MASt toolkit.

The DrupalGAP project does similar for Android devices going through PhoneGap.

What are the disadvantages?

You have to be aware of what you are giving up by not using Drupal directly.  Its easy to get caught up with the cool factor, and the newness of it all and forget how immensely useful Drupal is when it comes to building websites.

A few key things you’ll have to do yourself:


  • URL mapping – automatically making nice urls .
  • Redirects
  • Authentication – logging in and creating user.
  • Internationalisation – supporting different languages in your application
  • Caching – for performance


You have to look carefully at whether you need these, and the cost of implementing them.

That being said – there are ways to blend the two approaches to make things easier.

Authentication is the big one. Whilst services does supply methods for user creation, and authentication, I would recommend you don’t use them.

Either use another authentication scheme (OAUTH2 / social networking), or implement a user hub – and make that do the User creation / authentication for you. OAUTH will work for applications as well as HTML based properties.


Examples in the wild

This is a list of some notable headless Drupal sites, including the site Positive built for The Children’s Society.

· – foundation for apps front end

· built with Angular.js

·      The Tonight Show with Jimmy Fallon is using Node.js and Backbone.js


On to Drupal 8

Using headless Drupal, I believe, also starts you on the path to Drupal 8.

Drupal 8 has REST-ful services in its core.  Have a look at this Drupalize me article for a quick introduction

Drupal 8 core also contains guzzle ( an open source pure PHP http client that makes consuming REST services in Drupal a breeze.

Content negotiation won’t be shipped in Drupal 8 after all (see which is a shame, but I understand the reasoning.

Never the less, in the process of ‘getting off the island’, Drupal 8 has become an open platform with REST at its core.

As such, I feel that as we enter the period where Drupal 8 will be released, we’ll see a lot of integration patterns and hybrid offerings- as Drupal 8 takes a role delivering some functionality. Where instead of building a full D7 site, I am sure we’ll see content management in Drupal 8 feeding lightweight front ends. I am sure we will see Drupal 8 front ends to SOA applications, gradually migrating more content and functionality into the Drupal 8 layer.

Exciting times ahead… very exiting times.


In Conclusion.

Headless Drupal is fantastic if you approach it in the right way. Never lose sight of what you can get done in a standard site build, and don’t be too set on doing ‘full’ headless unless you think it’s absolutely the right approach for your project.

Being able to adopt modern front end tooling, and being able to integrate a CMS tool into other systems is a brilliant way to get more value from your Drupal skills and sites, and to get your Drupal skills into more places that might not otherwise have occurred to you.

Positive have released the demo code from a talk called Decoupling Drupal at Bristol DrupalCamp 2015. Think of it as a companion quick start resource for headless Drupal 7 - you can find that here.

Feel free to use the issues list there to ask questions, fork it and if you add something useful – please do issue pull requests.

posted by

Our new Drupal development infrastructure

Setting up Positive's development environment.

At Positive we've recently renovated and overhauled our development infrastructure.

Technology moves incredibly fast. Just as we are agile with the sites we build, we recognised a need to be agile with how we build them too.

Our natural conclusion was that one central development server wasn't the right solution any more. In this article, I'll go in to some of the things we've put in place, why we've done that, and how it makes things better.

Normalising our operating systems.

Originally we used Ubuntu LTS for our development server. Whilst this is a great solution, a lot of our live builds happen on RedHat Enterprise Linux, or Centos.

For this reason we have made the decision to standardise on Centos 7. This doesn't mean we won't use other operating systems. In fact our architecture means we can embrace differences in environments (more of this in the virtualisation section). Having a default - a standard we'll use, means things are so much more straightforward.

Whilst at the Drupal level you won't really notice the operating system you are on, all the other processes, tasks and activities will have an impact. Standardising on one operating system means we have consistency of these operations through all environments. This has both impacts on time, and on quality. As it's always the same now, we can develop a stable best practice and over time we just know what the right way of doing things is.

Virtualizing and Containerizing.

One of the old dilemas of LAMP hosting is the upgrade dependency hell you can get into. If you've got different versions of Drupal to support, plus some Wordpress, maybe some other specialised CMS work and other custom code - balancing PHP and mySQLl versions can be a nightmare. This is one area where virtualization steps in for us. We can have small and upgradable working components rather than a monolithic server we dare not upgrade as we dont know what will break.

What we have built is a Centos 7 host running libvirt virtual machines. Each developer gets a Centos virtual machine to develop on. We manage these via Foreman, which also acts as our Puppet master.

We have also added Docker to the main host. We use Docker for tools that cut across concerns - currently we have Docker running :

  • an html validator
  • a version of gitlist mounting a host folder containing mirrors of all our GitHub projects.
  • a Dockerfile that we have built for Continuous Integration of our Drupal builds.
  • a copy of DeepDream we've been playing with.

Consistency through recipies.

We are using Puppet to provision all our environments now; Dev, UAT and Live. Foreman acts as the puppet master and we use mostly community puppet modules, with some custom manifests.

This means we have consistency in our approach and consistency through environments. A bonus of this is that it democratises the environments. You don't have to be a sysadmin to add node.js to your development environment, you just select that class in foreman, puppet runs and you have node.js.

Puppetforge, the home of the contributed puppet modules is an amazing resource. Basically, it's a self contained, self documented best practice on server provisioning.

Some of the modules we use are

and we've recently written a puppet module for an HTML email development environment.

Continuous integration and repeated tasks.

We run Jenkins. We think he's pretty great too. Jenkins is built as a continuous integration server, but can do so much more. Jenkins is a replacement for all those scripts you collect over time and it provides a front end to processes that can be run on demand, or on a clock.

So - how do we use jenkins at Positive ?

Firstly, we use Jenkins for continuous integration - on push to develop , Jenkins polls the GitHub repository and pulls the changes. Jenkins then builds the site via a drush make inside a docker container, runs the Drupal tests, and runs a sitespeed test on the site. That is something close to the holy grail of Drupal development. All of this is for new builds only for now. We will roll this backwards as the need arises.

We also use Jenkins as a command and control server. Jenkins syncs down databases and files from live servers to our development environment. This way, if we need to build a test version of a site - we've got all we need to hand.

We use Jenkins as a test bot too - all client sites have a sitespeed test that can be run from Jenkins and we are gradually rolling in selenium tests.

We can run drush commands across all the live, and UAT servers from Jenkins (to clear cache, run update scripts etc.).


It's all still bedding in, but it's already proving it's worth. Having sites build on push to the develop branch in GIT, having a reliably consistent development environment and being able to try new things; either via a new VM, or a docker container. These all add up to a happy, agile development team.

posted by

Positive at DrupalCamp Bristol 2015

Some of the Bristol Drupal community on developer day

On Friday 3rd and Saturday 4th July 2015 Positive supported the first DrupalCamp in Bristol. 

A long time in the making. 

Since we’ve been in Bristol and developing websites with Drupal there has been talk of a DrupalCamp. Bristol has a vibrant Drupal community and it was inevitable that there would be a camp here eventually, it was just a case of when!

For six months we were part of the committee thatwas planning, preparing and organising the two day event, meeting every fortnight to get things ready. There were designs to be created, a site to be built, t-shirts to be printed and speakers to be arranged.


Drupal Camp Bristol 2015

A design to make Brunel proud.

One of the many ways Positive supported the DrupalCamp was through design resource and by creating the DrupalCamp Bristol identity and logo.

Capturing the essence of Bristol and of Drupal in branding that works large or small, on stickers, t-shirts and of course online wasn’t easy – but we love what we came up with.


The Business Day

The business day was based around a single track of events on the Friday from a host of business speakers (full list here: kicked off by the ever memorable and charismatic Jeremey McGuire AKA "jam".

Jam waxed lyrical on business and governement really embracing open-source technologies, specifically how European governments and local councils have changed the way they approach ther technlogy sets. Moving towards open source has had a huge effect on keeping investment within their local communities. Open source technologies can help us all keep our data and finance local, and help us all compete with the big boys on a level playing field.

Next up Kit Hunwicks talked about learning to love the brief. His insights on making sure that when tendering for digital products the objectives and goals of a product are specified honestly and clearly were solid advice for anyone on the other side of development from the agency and freelance bods in the room.

The discussion session included Positive's very own Founder and MD Mike Jenkins, alongside Nick Torday from Sift and Dan McNamara from Microserve. This insightful topic session covered everything from team make up, lessons learned from years delivering Drupal and how we can work better together as a community.

Ben Wilding from Cameron and Wilding took us into lunch with a talk based around a the variables of doing business and doing drupal. There was an excellent Q&A session for this talk where Ben asked the audience what they felt were the important variables of their businesses, including some deeper discussion around developing your business for growth or developing for purchase.

Following lunch, Paul Johnson from CTI Digital did a fantastic job giving insight into thir recent work with GOSH and how their processes had to adapt to work with the client. Of particular insight was how they used a highly experienced data planner who was not an obvious hire, but a perfect fit for mapping and translating the content and database records from old site to new.

Matt Connoly took us into the networking session. Currently ruuning a global innovation agency; Tällt, Matt gave an intriguing talk about startups and the traditional agency revenue model, suggesting that a move to partnership and revenue share can often be a far more profitable way to structure agency remuneration.

Going out with a bang! on day 1 we were treated to a talk by the ever wonderful Matt Jukes. Matt has been at the Office of National Statistics for a while now and his brutally honest talks highlight the highs and lows of taking a website that was described as "the worst website in the world" into a beta that people will love. Matt is always excellent value and was currently in the throws of a beta launch of the new ONS site.


The Developer Day

There were some great sessions on the Saturday (there a full list of what you might have missed here: and it was all kicked off with a great keynote from Leonie Watson on how accessibility has changed over the life of the web. 

It was a real honor to see someone using accessibility tools to use a computer, enabled by technology. The take away being that we’ve done the hard work making things work cross browser, and its down to us to ‘code like we give a damn’ to bring accessibility into everything we do was a powerful way to start the day. 

Marek Matulka from Sensio Labs gave a really interesting overview of bridging Drupal and Magento, using Symphony components from a Drupal 7 build. I can see this being a way to smooth the progress to Drupal 8, writing good object oriented code that we can use in Symphony components now seems a great way to lower the cost of entry to Drupal 8.

David Hughes from Cancer Research UK talked us all through the approach they took to theming Namely, a pragmatic use of SMACSS and BEM, designing in the browser starting on Github pages and moving to a Drupal theme when the design was ready.

A real take away was his recounting from the client that ‘it looks just like the design!’ , this approach meant it really was just the design. 

Mike Dixon from Computerminds took us through their build pipe, and visual regression testing. Their internal tool ‘jeff’ (codename) looks to be something that takes visual regression testing like wraith to the next level with easy to interpret visual differences.


Decoupling Drupal 

I gave a talk on our recent project with The Children’s Society –

This is a ‘headless’ Drupal site. I talked about the process we went through, the lessons we learned and the problems we overcame. 

I touched on the JustGiving implementation – and it turns out lots of people in the Drupal space are looking at this – including CTI Digital, FlowMoCo and us at Positive. 

To round out my presentation I gave a few technical demos, and I’ve released that code here : for anyone to have a look at.

It’ll give you a kick start on angular development with Foundation for Apps as a front end to a headless Drupal back end. Feel free to ask me any questions on that via either @timmarsh, or the issue queue on that project.


Integrating with Drupal

Ringo gave the final lightening case study on the work we did with Mytime Active, using Drupal to vastly simplify their IT infrastructure, integrating their booking system with their website via Drupal Commerce, and much more. 

Having the chance to look back at a large site build like that, with commerce, API integration and responsive designs make you realise just how much you can do with Drupal.

Ringo also told the best jokes, and rounded the day of on a high point.

All in all this was a fantastically successful 2 days. Many thanks to the organising committee , and here’s to next years event, and many more.

posted by