When Drupal Core's Block Configuration Just Doesn't Cut It, Try the Context Module

Recently, while explaining block configurations during our Drupal Essentials training, an observant pupil raised the question, "If we switch themes, do we need to redo all of our block configurations?". In Drupal core, the simple answer is, unfortunately, yes. But there is another, more powerful, way to control the display of blocks: context.

According to the Context project page, "Context allows you to manage contextual conditions and reactions for different portions of your site." The terminology of "conditions" and "reactions" is different than block configuration, but don't be frightened. This is just another way of specifying when to display which blocks (and more).

With Drupal's core block module, you specify how a block should display using a combination of URL paths and/or user roles. In Drupal 7, you may also use the content type to determine block display. Multiple URL paths and wildcards can be listed but the display logic is strictly an either/or affair and is typically driven by the URL path.

A sample block configuration screen for a block that appears in an About section

The context module takes a larger perspective. Moving up and away from the block-centricity of the block module, the context module works at the level of section or layout. Instead of telling an individual block when and when not to appear, you define a section (or context) and specify which blocks should appear. Like block configuration, this context could be determined by the URL path, user role or content type, but it may also come from the active menu item, taxonomy or user account page. In many cases, this eliminates the need for using PHP code to perform more advanced block configurations, which increases the maintainability and security of the site.

The same About section, but now specified with a context condition

But displaying a block is only one "reaction" among many in the Context arsenal. In addition to block display, context can be used to set breadcrumbs, active menu trails, add CSS classes and template variables and disable entire regions. That's a lot of theming power in one module!

The block display reaction for the sample About section

One advantage of using the core block configuration is that some themes (e.g. Bartik) provide a direct link to edit a block from the block's display location. This is a quick and intuitive way for users to modify the display or content of a block. Since contexts don't operate at the block level, this doesn't work for contexts. However, if you install the Admin module, you can get similar functionality with the context inline editor.  Also, contexts can be used in combination with block configurations. But, unless you are careful, this can get confusing, since this creates an additional set of configuration options. If a problem arises, this doubles the number of places to check. For this reason, it is probably wise to fully commit to contexts or take a systematic and intuitive approach to switching between one and the other.

Note that multiple contexts can be active at the same time and are cumulative when it comes to blocks. You may, for example, wish to use a site-wide context for a footer block. Since this block should appear everywhere, you could either enable it on every section of the site but why bother when you can enable it to a side-wide context?

Returning to the original question about redoing block configurations when switching themes, the context module does two things differently. First, your context exists outside of the theme layer, and therefore, will persist when you move from one theme to another. Secondly, because the context module was built with the CTools module, you may export and import your contexts. So, not only can contexts be used from one theme to another, they can be backed up in code or reused from one site to another. For simpler sites, this may only overcomplicate things, but when the needs exist, the Context approach merits serious consideration.