Drupal 7’s custom view modes allow you to display the same content across your site in different formats — without having to create custom templates or depend on detailed layout configuration embedded in views. However, there are also some issues, which, if not taken into consideration, can make building sites with view modes cumbersome.
View modes for newbies
So, what are view modes? The “Manage display” page ( Structure > Content Types > [Content Type] > Manage display ) for any content type configuration in the Drupal 7 admin is where you’ll find them.
View modes define ways to display a content type. Full content and Teaser come by default, but you can define other custom modes, each with its own settings and display order, for use in other places of your website or web app.
This is where field visibility and weight for each view mode (which are also sometimes called display modes) is configured. “Default,” “Full content” and “Teaser” are the default view modes that come with any standard Drupal 7 installation. You may also create and configure additional view modes that allow for any number of variations of field order and format — all without touching a custom TPL file.
Why view modes are great
Besides the obvious use of potentially limiting the number of custom templates required for your site, view modes offer several key benefits.
Since the same view mode can be configured differently across content types, view modes work well for providing a lateral perspective across content types. For example, you may have a landing page which displays a carousel of different content types (each with different fields). This is difficult to accomplish with views using field-based output. However, with view modes, the fields for each content type displayed in the carousel can be customized on a per-content-type basis, while still being generated through a single view.
Additionally, since view modes can be accessed programmatically via preprocess functions, they can also be used to modify field display, based on factors such as role or context.
The issues
So, what’s the catch, then? Well, first of all, unless you’re implementing a fairly small number of custom view modes (less than 5) in your site, if you jump right in and start setting them up without thinking ahead, you may actually be creating administrative problems for yourself (or the site owner) later on down the line. The larger and more complex the site, the more critical this planning stage is.
The key factor to using view modes effectively is to use as few of them as possible (but, obviously, as many as you need). After initially assessing how many potential view modes could be needed, you should, as much as possible, try to consolidate minor variations that would be better managed through CSS styling, preprocess functions and custom templates.
Some additional, potential headache factors include whether custom formatters are required, whether you are concerned with minimizing the use of custom templates or views, and how the eventual site maintainer (who may or may not be a Drupal-savvy client) will expect to administrate the site.
If you’re planning on joining fields, using custom formatters (such as date conversions, currency formatters and differing summary lengths or field wrappers, such as links), view modes get more complicated. Image styles incorporated into view modes may also need either custom formatters to permit image style selection. Depending on your needs and the developmental resources of the team, writing new custom formatters may not be a problem. For others, the Custom Formatters module provides a GUI to create some kinds of custom formatters which can then be, optionally, exported into code.
Since view modes add a layer of abstraction between content and theming, consider, also, how view modes will affect the maintenance of the site. Imagine this scenario: you’re looking at a panel-based homepage, configured with a number of view modes applied to different panels. You need to remove or add a field to one of the blocks, so you mouse-over the panel/view’s contextual links to edit the block. Then, from either the panel or view configuration screen, you’ll be able to identify which view mode is in use. From there, you have to navigate to the “Manage display” screen for the content type. Now, imagine doing this every time you need to tweak a single field on a site where a few dozen view modes are at work. Not my idea of a good time!

The display parameters of view modes are not governed directly within Views, making field-level changes to display just a tad more involved.
It’s also important to keep in mind that individual view mode configurations (as applied to content types) are not as easily exportable/importable as field-based views are. Theoretically, you can accomplish this through Features, but Features has its own complications in terms of site maintainability which may or may not suit your environment. Consider the potential need to make changes across multiple content type configuration screens vs. making changes on a master view that automatically gets applied to all child views.
Finally, think about an overall convention you’ll use to identify distinct view modes. You could (A.) use a single view mode with an arbitrary label (such as ‘teaser a’) to represent a specific output of fields across content types, or (B.) use a descriptive label (such as ‘homepage teaser’) for a view mode that relates more to the content’s context and then employing it differently, as needed, depending on the content type. The former method (using arbitrary labels) may prove more practical when a larger number of view modes are in place, since the subjective interpretation of contextual labels on different pages can prove confusing.
The design process
To recap, here are a few steps that will help you plan how to best implement view modes on your site:
- Analyze all of the site’s layouts; identify every display variation for each content type.
- Consolidate the variations into the fewest possible number that will facilitate your content strategy.
- Determine which view modes apply to which content types.
- Decide on, and document, a convention of labeling view modes which makes sense for how they are being used on the site.
- Build the view modes!
The build
Building view modes, is, thankfully, the easy part. Creating and configuring custom view modes is a simple, two-step process. First, the view mode is instanced. Secondly, it’s added to and configured for each relevant content type.
View mode initiation can be done through a module, such as Entity view modes, however, the code is easy enough to add to a custom module:
<?php
/* Add custom view modes */
/**
* Implements hook_entity_info_alter().
* The first attribute in the array defines an arbitrary label for the view mode machine name.
* 'custom settings' => TRUE displays the view mode as a default at the top of the display modes settings screen
*/
function hook_theme_entity_info_alter(&$entity_info) {
$entity_info['node']['view modes'] += array(
'view_mode_A'=> array(
'label'=> t('First View Mode Name'),
'custom settings'=> TRUE,
),
'view_mode_B'=> array(
'label'=> t('Second View Mode Name'),
'custom settings'=> FALSE,
)
);
}
/* Add custom templates for view modes */
/**
* Implements hook_preprocess_node().
*/
function hook_theme_preprocess_node(&$vars) {
if($vars['view_mode'] == ‘view_mode_A’) {
$vars['theme_hook_suggestions'][] = 'node__view_mode_A’;
$vars['theme_hook_suggestions'][] = 'node__' . $vars['type'] . '__view_mode_A'
} else if($vars['view_mode'] == 'view_mode_B') {
$vars['theme_hook_suggestions'][] = 'node__view_mode_B';
$vars['theme_hook_suggestions'][] = 'node__' . $vars['type'] . '__view_mode_B';
}
}
?>An extremely helpful bit of code to expose the node title and authoring metadata to the view mode ‘Manage display’ screen has been shared by Tim Cosgrove. He’s also developed a plug-and-play module which performs the same functionality if you don’t want to mess with your own code.
After all the necessary view modes are created, you’ll visit the “Manage display” tab for each relevant content type, activate all relevant view modes for that content type, and configure field visibility, weight and custom formatters for each view mode.
Once the view modes are defined, they can be enabled under the "Custom Display Settings" for each content type.

On the “Manage display” screen of your content type, scroll down to Custom Display Settings to toggle which view modes are activated for that content type.
Once configured, the only thing left is any necessary templates and the CSS to style your view modes according to your design specs.
Conclusion
Once you start using using them, you’ll start to appreciate how view modes offer a whole new world of possibilities for managing and displaying content throughout the various layouts of your site.
