When I joined Weill Cornell Medical College, one of the first orders of business for the Web Communications team was to roll out an institution-wide Drupal distribution. The distro bundles a collection of modules and features, all of which get pre-configured during site installation. This gives the site builders a nice custom start state that is much further along than a typical vanilla Drupal install, providing a nice boost to each production effort. The big selling point, of course, is that we can now easily deploy upgrades and new features to all of the sites running the distribution, which provides a lot of value for the stakeholders and ensures the sites under our care stay up-to-date.
A key decision we made early on was to build the distro on top of the Panopoly project. Panopoly comes with a large collection of contrib modules that are curated and configured to play nicely together. You could say it is a "Panels-powered" flavor of Drupal. Instead of using standard Blocks, it heavily leverages related tools such as Panelizer and Fieldable Panel Panes for page assembly. By using these tools in tandem, a site builder or editor can easily customize their pages. The tools allow you to drop in a variety of different panes and content widgets, drag-and-drop them around, and even manipulate the layout. The best part is that these tools are pluggable, meaning that you can tap into this system and provide admin functionality tailored for your own particular requirements. Also, almost everything is exportable in Panopoly, which means that it is stored in code for easy change management and deployment. We followed that pattern at WCMC, using the following three components as the main building blocks of our own distribution.
Features is probably the most important aspect of our distro. If you're not familiar, this module allows you to capture a variety of configuration tasks and export them as a discrete bundle. For instance, let's say you wanted to provide a feature called "News Room." You could first build the content type and add any custom fields. Then, you configure the Panelizer template1 settings for the node type, setting how the fields should display in the selected layout. Finally, you build any related Views for the News Room, such as a teaser index, archive by date, or category. Then all of these components are selected through the Features UI and exported as a custom module. When you turn that Feature on...BINGO. The complete package is available for the site admin to use.
Panopoly provides a nice "Content Page" Feature using this method. At WCMC, we've done News, Profiles, Downloads and a few others. Basically, whenever we see a pattern of content that gets used over-and-over on multiple sites, this is a great candidate for building out a Feature.
Another tool we use heavily in our distro is what we like to call "Smart Panes." These are technically called CTools Content Types (a name that could be confusing). You can think of them like Blocks that are created in code, but are much more savvy. The plugin system allows you to define a pane and provide a callback with any custom code. They then get exposed to the user in the admin. These panes are meant to be dropped into pages across the site, as needed, whether that be in a Panelizer template (so they appear on every instance of a node) or as a "one-off" addition to a particular page.
The cool thing about these panes is that they can be somewhat intelligent. First, the plugin system allows you to provide a custom settings form. This means editors can configure the pane in the admin, and these settings will be considered in the display. Second, they are "context" aware, so your pane has access to node information and other data about where it lives. This makes it easy to get at fields on the node, or use the context for conditional display.
We use "Smart Panes" quite a bit. One example is for our Localist event calendar pane. This pane allows the admin to simply select a department and some other preferences, and it will go out and retrieve that department's calendar events from the Localist API and display them on the page using a theme template.
Custom Content Widgets
One thing that historically has been harder than it should in Drupal is placing arbitrary pieces of content on a particular page or set of pages. Over the years, many times I've been asked during a client training, "But what if I need text or an image on JUST these pages?" You could use blocks, of course, but the display logic and management UI was just not that intuitive for site admins. There have been multiple attempts to solve this problem, such as the Boxes and Bean modules, but my favorite approach so far is the use of Fieldable Panel Panes.
Fieldable Panel Panes are reusable entities that can have custom fields and can be placed in Panel layouts. Think of them like blocks that can have fields and are really easy to place on any page. Panopoly provides panes for text, images, files, links, tables, maps, video, among others. The cool thing is these are also pluggable. You can add your own types of content widgets with custom fields and display.
Panopoly does a lot of work to ensure that this workflow is a pleasant experience. Along with the In-Place editor, this allows a site admin to choose the region of the page where they want to add a piece of content, select which type of content they want to add, and then just fill out a form to input it. These can also be dragged around to the other regions on the page, if needed.
At WCMC, we were being asked by clients for the ability to build various "people" pages. These were not quite like our profile directories, as they often included non-faculty members. The site admins also wanted to be able to group and order them independently, and the kinds of people varied by department. Some were making pages of staff, some students, and some a mix of committee members, etc. To mange this, we added a custom content widget called "Headshots." This widget had an image field (with associated image style), along with some fields for contact information or short bios. In short, it was generic enough to accommodate the required variety, but structured enough to ensure that the display looked consistent across our sites.
It's been an interesting experience being part of a team building a Drupal distribution. It's necessary to think about sites as being part of a system, rather than a one-off. This has produced a closer collaboration between designers and developers, as we plan future improvements. And while features are rolled out easily, you also become vigilant about making sure any addition or modification will deploy cleanly, as any bugs that get introduced will affect many sites.
Even if you're not a part of a large institution, I can see the value of putting together a distribution. Having a collection of go-to modules, pre-configured with an install profile, and prepared with features ready to be turned on with a click is a great recipe for consistent production in Drupal.
Panelizer lets you control the layout of a content type with a drag-and-drop interface through the admin area. No more node.tpl.php. ↩
Back to the Work section »