Blog

It's always instructive to see what tools a Drupal shop uses when building its own websites.

So what did we use in redesigning drupalwatchdog.com?

Display Suite

We used Display Suite to provide layouts and enhance Drupal core's basic entity view mode configuration.

We added custom view modes as needed. Since the design called for placing fields in site-wide theme regions, we used Display Suite's Region to block functionality, which allows you to assign content to core theme regions when configuring an entity view mode.

We also made extensive use of Display Suite custom fields. Code fields, preprocess fields, dynamic fields--we used them all. We also used a Display Suite API hook (hook_ds_fields_info()) to declare custom fields as needed--for example, to present social media links on article nodes.

For related lists - like other articles in this issue or the contributor for a given article - we used the "content pane" views display type provided by CTools, adding one or more contextual arguments and configuring the content pane to allow arguments, then adding the pane to displays via Display Suite dynamic fields.

Custom Callbacks and Render Arrays

One limitation of Display Suite is that it isn't particularly suited for building one-off pages with custom layout. For our home page, we used a custom menu callback, returning render arrays for ease of manipulation at the theme level.

Bootstrap

We've used the Bootstrap base theme on several projects now, so it was an easy choice. It doesn't hurt that Mark Carver, the themer on the project, is a leading Bootstrap theme contributor.

Features

We follow a typical dev/staging/production workflow. For drupalwatchdog.com we developed several custom modules using Features to hold both exported configuration and related customizations.

We used Context only for block placement, supplementing with a Drupal hook implementation (hook_block_view_alter()) as needed to customize block titles.

Code Management and Deployment

As usual, we managed the site code in Git through Github, with each developer pushing to a personal fork and opening pull requests when peer review was needed. For local development we used Drush to synchronize with the production site database and Stage File Proxy to fetch files on demand.

Ticketing and Team Communication

We use an in-house ticketing system built on the Support Ticketing System module. The main place for team communications is an internal IRC channel (integrating the Bot module). For a distributed team, IRC provides essential real time exchange to talk through ideas, answer questions, and get support.

At project startup, the tech lead generated tickets for each area of functionality, working from the comps and identifying outstanding questions. Before building out a given page, we typically reviewed it together, to ensure what we were building fit the needs of Mark, the themer. Conversations would go something like:

Tech lead: So the list on the main content area looks like a custom view mode showing some basic article fields and then maybe a preprocess field for the article date. Does that sound right?

Themer: Yeah, that should do it. Remember though that you can't use a DS preprocess field with "Block to region". So for that you should use hook_ds_fields_info().

Tech lead: Got it.

To help make sure code met his theming needs, Mark also sketched in some stub callbacks as needed. That gave the developer implementing the work a clean model to work from and helped ensure we didn't have to do a bunch of refactoring later.

Tickets included basic instructions for implementation, like:

• Configure a view of type content for "Other articles from this issue" article listing.
• Add a contextual filter for the issue, excluding it.
• Add a Content pane display, configuring the argument to be passed from context, selecting "Content ID" for the context.

Design-specific Solutions

Each site design raises its own requirements. For previous and next links, we used the Flippy module, along with some fairly complex customization where we needed more specific paging--flip through articles first by the publication date of the issue they appear in, then by page number in the print publication.

We needed an image style with a blur effect for the background image displayed on the home page and elsewhere. While such an effect wasn't included in available modules, we found and adapted a patch from the Image Magick issue queue on drupal.org.