In January, our team worked in partnership with ProMotion Arts to launch a conference website for the Bill & Melinda Gates Foundation. The Gates Foundation is currently very active in examining the U.S. school system looking for effective ways to leverage its strengths. Our team had the opportunity to participate in building online tools to help stakeholders connect at the annual Teaching is Learning 2013 conference (they call it their "convening").
As a front-end developer, this project was interesting because we were building a fully responsive website in a short time frame. This meant we needed clear mobile-first designs with clear layout guidelines.
Imagine never having to click around your website after a site update, worrying that something may have broken. Imagine never getting a call from a client after a site update, telling you that something in fact has broken.
What if instead you could script all the actions that you would normally do by clicking and have those automatically run each time you push new code to your code repository?
All this is possible using Behat, Mink, Drupal Extension, and Travis CI.
This past week I've spent some time creating a proof of concept test suite for a Drupal distribution. I began with the Drupal 7 standard install profile. This will be a walkthrough of the additions I made to add testing to the distribution.
Follow along with the code in my [Classic] GitHub repository.
Behat is a PHP framework for [Behaviour Driven Development] (BDD).
Have you recently checked out your website on a cellphone, or a tablet, or another mobile device? You may have found yourself scrolling and zooming in and out in order to be able to read its content. All this headache can be avoided by adding a responsive design to your site, but what exactly is a responsive design?
...an approach to web design in which a site is crafted to provide an optimal viewing experience—easy reading and navigation with a minimum of resizing, panning, and scrolling—across a wide range of devices (from desktop computer monitors to mobile phones).
A nice technical definition, but what exactly does this mean? Well, imagine that we have the following set of devices: a nice big monitor with big resolution, a tablet, and a cellphone.
We have several projects that involve processing large geospatial datasets
(geo-data) and displaying them on maps. These projects present some interesting
technical challenges involving the storage, transfer and processing of
geo-data. This post outlines some of bigger challenges we have encountered and
our corresponding solutions.
In the past we have used the GMap and
OpenLayers libraries and their equivalent Drupal
modules on our mapping projects. They are effective solutions when you have
a small or even moderately sized collection of entities containing some simple
geodata (points, lines, polygons) that you want to present as vector overlays
on a map. Unfortunately they tend to fall apart fast when you attempt them with
larger datasets. There are two main reasons for this:
Geospatial data can be large, particularly as we tend to encode it in
text-based formats such as WKT or GeoJSON when we are sending it to a web
browser. The larger the data, the longer it takes to transfer from server to
A great opportunity arose a few months back when Tom Nightingale and I were each beginning work on client sites needing advanced search functionality: the Search API module, providing "a framework for easily creating searches on any entity known to Drupal, using any kind of search engine" was becoming more awesome and more stable by the day, and the FacetAPI module had just been announced, but there was no integration between the two.
The attraction to Search API, for the project I was working on at least, arose from some initial uncertainty around whether we'd be using Sphinx or Apache Solr for the backend, and from the fact that we definitely wanted to use a Views front-end for displaying search results.
Five years ago Dries blogged about distributions becoming an integral part of the Drupal ecosystem. He saw a future for Drupal that included tailored products for many different markets. Today there are a large number of distributions targeting many categories. In this post I'm going to discuss Build Kit and how it can be used as a platform for building and maintaining distributions and custom site builds.
This post is part of our Abridged series, which aims to explain the basics of some of the more ominous yet awesome Drupal projects in simple and practical terms. We hope these posts will help demystify some of these projects for people who have been hesitant to try them out!
Here, we'll take a look at Boxes module, including a review of its history within the Drupal project, the current state of the module, how to start using it, how we use it at Affinity Bridge, and some resources. Special thanks to Tylor who recently did a sitdown (team discussion/learning session) on Boxes module, and wrote the technical sections of this post.
Boxes module is a Drupal project that was originally built by Jeff Miccolis from Development Seed. It's been around for quite a while, but many people don't venture into using it, largely because it's not clear upfront what the benefits are over core Blocks.
At DrupalCon Chicago this past week, there was a "Core Conversations" session track, made up of sessions pitched by contributors to the core Drupal project. A wide range of topics were covered from the Butler project (a new system for context and blocks), to the built-in Help system, to Deployment strategies, to redesigning the issue queue. These sessions were shorter presentations followed by a discussion period for the attendees to give input on the topics.
Late Tuesday night was one of the most exciting Drupal events I've yet to be part of: the official release of Drupal 7. I've been working on the Drupal 7 documentation for over a year at this point, and crunching really hard the last few weeks on the Install and Upgrade guides, and core module documentation. I knew the day was coming, but it was even more inspiring than expected being a part of those last few days and hours leading up to the launch.
When Angie (aka. "webchick", Drupal 7's core maintainer) started rolling the release, it was quite obvious how excited everyone was on IRC, as this went on for about five minutes straight after she created the final release: