You are here

This was the first (and main) project that I was involved on in my initial period at HTB.  It is their flagship site, and had a strict deadline due to their big event (Focus) which was happening in August.  It was a D7 site, and required a lot of new functionality, whilst also pulling in content from the old site.  Some of my main responsibilities on this project are listed below with a little more detail.


Senior Developer

The senior developer for the organisation in general had a lot to work on, and therefore my responsibility was to take some of that load, being one of those projects.  The team was small, with myself and another developer working the life of the project, with another back-end developer coming in to help with SSO and media section, aswell as a front-end developer for a short period aswell.  Within this team, I needed to help answer questions, ensure everyone was talking to the right people, and help progress the project at a suitable speed.


Scrum Master

Whilst HTB wanted to use Agile methodologies, this hadn't been enforced to a strict degree.  Therefore in my first few weeks I headed to a talk at eBay on how they have Agile setup, and with my experience at Comic Relief, proceeded to restructure their JIRA workflows, and get a nice Agile process in place which worked better for them.  It took a few iterations to get something that worked, and that everyone understood, but once it was in place, everyone seemed very happy with it, and it is now used on more projects that I am not involved with too.


Rules and emails

This was focussed on the 'connect' section and the site and started off as a webform that sent emails to different people depending on what fields/checkboxes were used.  Now, the first part is fairly easy as we just setup a webform with rules listening for submissions.  I then got rules to analyse the content, and integrate with another module called 'messages' which handled the content of the outgoing emails because the content, aswell as the recipients needed to change depending on the form results.


Flags and the Calendar

The calendar was one of the big selling points for the client on this new site, this is because they promote a lot of events throughout the year, and they wanted their users to be able to add these events to personalised calendars on the site.  This proved to be quite fiddly, initial work was not to bad as we use flags for users to add items to their calendar, and then views to present the results back.  The issues came in when some content that needed flagging was actually referenced by other content, which required views relationships to be setup, and detailed testing to find all the little bugs as they came up.



Not too complex, but an important part as users need to find churches and locations, so each location has a map, and the flagship locations have pages with directions on too.



Podcasts are always a little bit of fun, due to the media section having a cimplete overhaul, I needed to rewrite how podcasts work.  Luckily for me there are nice modules which allows us to use views for this, also the old site uses feedburner, which means the iTunes endpoint didn't need to change, I just needed to point feedburner to the new url.  Whilst doing this, I recommended a slight restructure to podcasts to add variant options in for users that only want one type of media (video/audio/both), this was agreed and implemented in the backend ready for promotion.


Instagram management

This was a module supplied to HTB by another development team.  Sadly this wasn't complete at the time, and the code was not done using regular Drupal entities for things.  This took some time to understand the ins/outs of, and then finally complete the functionality, fixing all/any bugs as they were found.  Part of this was to improve the performance of this b caching content better, and compressing images using imageAPI



There was no in-house devops team on this project, and therefore due to my experience with varnish, I set aside some time to improve how their setup worked.  The initial configuration was largely not caching anything due to various cookies and a lack of tlc.  Therefore once varnish was upgraded to 3.0 we added in some standard D7 varnish configuration before making a few custom modifications to allow us to do some clever purging aswell as telling it to ignore some cookies.  Once complete, all assets/css/js was getting cached, and most pages for anonymous users was also cached.

Mon 7th Apr 2014 to Fri 19th Dec 2014
Developer: Senior
Drupal Site