by Aaron Froehlich

Drupal has emerged in recent years as an extremely flexible and powerful resource for creating web applications. It's done that by creating an infrastructure that simplifies the process of building new functionality and an ecosystem that encourages developers to share this custom functionality. This has been a winning approach because it appeals both to highly-skilled developers who want to contribute to the open source community, as well as relative beginners who want to build rich applications without needing to write or even grasp fundamental programming concepts. The result is an ecosystem that has really thrived, with thousands of modules and a world of possibility.

However, Drupal's strength has also created a number of real problems for developers, particularly related to the long-term maintenance of those sites. The ability to piece modules together has created what some are referring to as the "open buffet syndrome", the alluring tendency for companies to incorporate large numbers of modules to meet the needs of a given project. This approach has a major impact to the total cost of ownership (TCO) of Drupal sites. It not only complicates development tasks like maintenance, updates and upgrades, but it also complicates the administrative interface and site management. Furthermore, the open buffet approach often leads to frustration for developers, who typically prefer writing code to configuring modules, leading to what some refer to as Drupal's Golden Handcuffs. 

We believe that there is a better way to develop for Drupal, which we've been referring to as "Minimalist Drupal Development". We first began thinking about MDD after reading the Treehouse Agency's article about building the energy.gov site without Views, and it just made sense. Our years of Drupal development have proven to us just how essential module selection and implementation is for a project, and how costly poor choices become over time. MDD relies on limiting the use of contributed modules, as well as leveraging Drupal core and its APIs. This creates a more performant system with fewer bugs and fewer patches to maintain, therefore lowering the TCO of your projects. It also requires that you spend more of your time writing code than configuring modules, one of the keys to developing for Drupal and loving it.

When Cornell University's College of Agriculture and Life Sciences (CALS) came to us last year, we saw an opportunity to fully embrace MDD. CALS needed a Drupal install profile that they could use to launch up to a hundred different sites, which prioritized a simplified user interface, a robust permissions and workflow system, and a range of reusable content blocks that integrate into their page workflow. So, how did we do it?

To start with, like energy.gov, the CALS platform is built without the Views module. To achieve the client's goals, we made extensive use of the Bean module, and combined that with the Block reference module. Each page on the site includes three block reference fields that allow our custom beans to appear in the first or second sidebar, as well as in the main content area. To get them there, we simply leverage hook_page_alter() to pluck them from the render array and add them to the appropriate region on the page. This has the added (and in this case, required) benefit that all of the relevant content on the page, including the blocks placed in the sidebars, gets added to the revisioning workflow and can be reverted.

There are additional advantages to using Bean that reduce the overhead on the site. For example, CALS events are managed through a 3rd party API. The traditional approach would likely include using the Feeds module to import the data into an event content type. However, that approach introduces all the associated complexities of managing duplicated data, such as how to handle edited data in one of the systems, setting up cron to keep data current, etc. Using our minimalist approach, Bean made it trivial to grab the json feed of events, cache the results, and display the block (bean) of json nodes to the user without even needing an event content type. There's no duplicate data to unify, and it takes all of 30 seconds to provide the necessary keyword(s) to include in a new block of events and get them onto a page.

Bean is just one key strategy we employed in the service of our MDD philosophy on CALS. In the future, we look forward to blogging about other strategies, including the types of choices that allow you to leverage Drupal core, and how to judiciously choose and even borrow from modules without going for a new plate at the buffet. Stay tuned as well for more about the automated test suite we wrote using Behat and Mink, which provides a full-coverage test suite for all the key functionality of the platform and provides an insurance policy that will allow them to run security and module updates with confidence. And perhaps the most important argument for MDD, from one code loving developer to another, is that we were able to build the site while spending 95%+ of our time in a text editor rather than a browser. 

So what strategies are you using to support Minimalist Drupal Development?