Dec 06 2017
Dec 06

A Lifecycle Approach to Configuration Workflows will show watchers how Drupal empowers users to build complex site structures and relationships directly in the administrative user interface. In Drupal 7, the Features module was repurposed to manage site configuration deployments across environments. This developer-oriented workflow is now built into Drupal 8 core. But for small to medium-scale projects, strict configuration-based deployment workflows can be cumbersome and require substantial development expertise. So, how do we ensure the benefits of versioned config management after the original developers have moved on to greener pastures?

Fortunately, the configuration system is flexible and supports a wide range of workflows. A database UI-driven workflow is well-suited to rapid site prototyping and content modeling. A config-git-driven workflow pays dividends when scaling up the development team and performing automated tests. A live production site has a wide range of options for balancing rapid delivery with version control. Identifying and communicating the phase of work in a project’s life cycle and shifting workflows accordingly will improve development productivity and increase the diversity of contributors on a project.

Key Concepts:

  • History of configuration management

  • Competitive pressure within the CMS industry

  • Enterprises and Drupal

  • Configuration management in version control

  • Tricycle manifesto: build - prototype - build - maintain

  • Best practices

A Lifecycle Approach to Configuration Workflows

[embedded content]
Apr 06 2016
Apr 06

Just in time to document the New Hampshire presidential primaries, WGBH News, with the help of Isovera, released a redesigned website, wgbhnews.org. Breaking out of the dated layout of a fixed-width desktop with separate mobile-friendly site, the redesign features a fluid responsive design, finger-friendly touch targets, resolution-independent vector art and a component-based front-end. The new design builds and expands upon the friendly branding of the parent WGBH site while supporting a nearly unlimited range of device sizes.

A Fluid Responsive Design

The quick test for a responsive web design is to drag the corner of a browser window and observe the reflow of elements on the page. A design based on fixed breakpoints will show sudden layout changes as the layout reorganizes at each breakpoint. A fluid design smooths the jerkiness by delegating the breakpoints to the individual components of the page. Instead of reformatting based on context, each component adapts itself to the width of the screen.

A fluid design especially shows its merits when changing the browser font size, a key feature for accessibility. By building content containers with a unit of base font size, using root em units, rather than pixels, the entire site adjusts to font size change as easily as browser width. As reasonable as this sounds, you would be amazed at how many sites were not designed with the ability to scale in proportion to a user-adjusted font size.

In the following screen grab, the font size is gradually cranked up, demonstrating the fluid transition from a full desktop display to the more linear mobile phone format, all while maintaining perfect usability and design fidelity.

Stepping up the font size

Animation of wgbhnews.org font size increase

Unfortunately, not everything can be truly responsive. While the Doubleclick for Publishers ads are billed as "responsive", they are not in the sense prescribed by Ethan Marcotte in 2011 and definitely not fluid. The ad sizes are served for each page load at a fixed width according to the page width. This means that the site visitor has to refresh their browser to display a resized ad if they change their browser width beyond its breakpoint. This demonstrates the sorry and dated state of the online ad business. It's no wonder that the industry is due for a shake-out. That said, many sites, including wgbhnews.org, necessarily rely on online advertising services.

Device Independent

If you stop and think about it, the terms "mobile" and "desktop" are rather irrelevant now. Is the 12.9" iPad pro (2,732 x 2,048 pixels) a mobile or a desktop device? What does it mean if a Samsung Galaxy S (720 x 1,280 pixels) has practically the same pixel dimensions as a common 14" windows laptop (1,280 x 800 pixels)? The mobile/desktop device dichotomy is stale. What really matters now for web design is designing across screen size, resolution, orientation, and interface (e.g. mouse, touch, or keyboard).

Resolution Independent

A high resolution screen or average smart phone has a pixel density that reveals the blurry edges and definition of older images. Switching to a retina screen is like wearing glasses for the first time. The detail is not a luxury, but an alignment of the technology with our ability to see and our ability to see clearly. For this reason, the logos and icons on WGBH News are rendered with vector art using SVG. They support whatever resolution the device can render. The following screengrab is a zoomed in snapshot of a fraction of the site's logo directly from the website. The signature angled lines remain bold and crisp.

A closer look at the header branding

Zoomed look at WGBH News logo

Not only are SVGs sharp, they have a relatively tiny file size. And since they are also markup, they can be embedded directly into the web page's HTML, reducing the number of server requests. The instant your browser downloads the first byte of a WGBH News page, it can begin to render the branding and navigation icons as well.

SVG is not a new technology, by the way. The specification was originally introduced in 1999 and debuted in web browsers in 2004. However, it is only recently that SVG has exploded in popularity. Several years ago, icon fonts were a common approach to provide vector art, but their applications are limited and they are a challenge to maintain. But, now that Internet Explorer 8 has reached it's end-of-life, browser support for SVG is practically universal. That said, we did include PNG image fallbacks for those poor WGBH News readers who are still stuck on IE8.

Responsive Images

And you better believe that screen orientation matters. We baked one assumption into the WGBH News site, which is that smaller screens tend to be held at a vertical orientation, rather than horizontal. A hero image for a lead story must adapt its aspect ratio or appear awkward. Fortunately, the picture element (and Drupal module) handles this resolution change with little effort.

Vertically, this photo appears at an aspect ratio of 16:9. Any wider and the image would appear as a narrow band and deemphasize it's content.

iPad portrait

Horizontally, this photo displays at an aspect ratio of approximate 7:3. This proportion keeps the image from occupying almost the entire screen.

iPad landscape

Design System

When establishing a design, a system is conceptualized for branding identity, thematic consistency and language across the site. It is always a challenge when new features or developers are added to maintain this system and reuse the existing patterns. Style guides have enjoyed a resurgence in popularity for this purpose. Popularized by web developers such as Brad Frost and Anna Debenham, style guides provide documentation for the visual elements and language of a design system.

While the design team at WGBH News Digital Services created design comps with Adobe InDesign and furnished basic elements of a static style guide, Isovera helped to convert these design artifacts into web-based HTML and CSS that would provide a long term solution to these challenges.

Development Toolkit and Workflow

There were a variety of ways that we could have approached the redesign, but we were bound by two legs of the iron triangle: schedule and budget. We had to beat the deadline of launching before the NH primary and reserve a good portion of the budget to develop a robust back-end as well as migrate the pre-existing content and media. Given these constraints, we had to work efficiently and judiciously. 

The traditional waterfall approach to development is a linear process with a sequence of deliverables from one phase to the next. Waterfall can work well with requirements that can be well-defined in advance of implementation. But as you can see from the diagram, this approach is not good at incorporating changes as they arise further along in the process.

Waterfall model

To reflect their brand identity, WGBH News provided an in-house design and front-end development team. In the traditional waterfall development workflow, these distinct teams would have wasted considerable time stuck in bottlenecks, waiting on deliverables and managing inconsistent code. To support this design implementation, Isovera pioneered use of a living styleguide workflow. As you can see from the diagram below, a living style guide enables parallel lines of development as well as a more rapid feedback loop based on the surfacing of design problems in real markup and more representative content.

Living styleguide model

Component-Centric Architecture

By itself, the work derived from the living style guide can be a challenge to map to Drupal's core templating system, such as node and field templates. To streamline this process, Isovera engineered a component templating system that works in tandem with the living styleguide. This provided tremendous value in the ability to organize the various front-end patterns.

To get a better sense of how this works in practice, let's take a look at some code for a very simple component, an image credit.

Image credit - display

In this screenshot, we can see how the image credit will look when rendered. Note that the credit (outlined in red) is on the same line as the caption and shares its font properties. 

Image credit - handlebars partial

Based on the semantic and display requirements of the component, the front-end developer writes the markup for the styleguide. In place of sample content and potential CSS class variants, handlebars variables are used (the double curly braces).

Image credit - sample content

Next, the front-end developer adds a JSON file that maps the handlebars file to sample content.The variables will be replaced with this content when the styleguide is generated.

Image credit - sass partial

Next, we add the style rules for display. The CSS generated from this partial is used in the styleguide and the final site theme. This is the critical difference between a traditional style guide and a living style guide. The CSS must work and be maintained in both places. Additionally, another style sheet is generated for use in the Wysiwyg editor for content administration.

In this particular component, the `.credit` class is set to display as an inline element and inherit most of its properties from `%typography-small-text`, one of a set of more generalized Sass placeholder classes used to standardize the typography.

Image credit - component template

Finally, a back-end Drupal developer adds a component template to the same directory, which is contained in `sass/components`, not the typical Drupal `templates/` theme directory. This juxtaposes the PHP template used by Drupal to render the component with the style guide markup and content variables and the style rules.

Without the component templating system, the markup for this field could come from an almost unlimited number of sources, making it very difficult to troubleshoot and maintain. This is a problem that has plagued Drupal and made it into a specialized discipline. By consolidating the markup and presentation in a single directory, the components are much easier to maintain and reuse.

You might be wondering, "Why not use the same template file for the styleguide and the site, just like the CSS?" Great question! Ideally, the PHP template and the styleguide handlebars file would be one and the same. But that would require using a different templating system in Drupal 7. In Drupal 8, however, this is much easier, since Drupal 8 templates are based on Twig, which already has several JavaScript implementations.

Coding Standards

In addition to generating the style guide, we use the Gulp task runner to apply coding standards, or "lint", the Sass and JavaScript code. Since we are using the Drupal 8 SMACSS-BEM methodology, the linters are very helpful to keep all of the developers on the same page and enforce coding standards. Whenever a change is made, the code is compiled and a warning appears if there is a departure from the recommended standards. This keeps the codebase consistent and therefore organized and readable.

Flexible Layout

Components, by themselves are not a website. We need a way to assemble and organize them on a web page. For this, we used the Drupal Panels and Paragraphs modules. In place of an ever-proliferating collection of page templates, panels unifies the page layouts and allows a site administrator to reorder the components at the region level, e.g. sidebar and main content area. By exposing our components as CTools plugins, we are able to drag and drop them into position.

How to handle spacing between the components was not always obvious. Should the individual component partials include, for example, bottom margins? Or should those be handled at the page layout by Panels? With some experimentation, we found that the answer was not always obvious. Ultimately, we standardized the spacing at the region level, and often superseded or enhanced that spacing within the individual components.

For handling layout within the body of an article, we built on top of the Paragraphs module, to allow content editors to drop in a predefined set of components, such as embedded  video, slider, etc. For more information on the content editing experience, see our project case study, WGBH News: Building a modern digital newsroom.

The Greater Whole

Taken individually, the various aspects of the WGBH News redesign are valuable features. But incorporated together, we found that these features reinforced each other and contributed to a more efficient and effective development paradigm.

Feb 17 2015
Feb 17

Lately, whenever we start a project at Isovera, we are typically asked, "would you build this with Drupal 8"? It's a good question. There are many good reasons to get a leg up with the (currently) beta release, but there are also good reasons to keep your head down and stick with Drupal 7. The official release of Drupal 8 is rapidly approaching. What might this mean to you?

There are lots of reasons to get excited about Drupal 8. It's built for responsive web design to the core with mobile-friendly administration and state-of-the-art image handling. The authoring experience has been revamped with an improved content editing page, built-in WYSIWYG, and in-place editing. With RESTful web services and an object-oriented architecture, Drupal 8 is a first-class, open source content management system. You can really treat your content as a system of interacting components rather than a jumble of web pages. That's just the the tip of the iceberg. There is a whole lot more. Needless to say, these are very compelling features, but they don't necessarily justify a Drupal 8 migration just yet.

Wait, “migration”? Don't you mean upgrade? Nope, Drupal 8 is so radically different from Drupal 7 that a standard upgrade is no longer possible. Content will have to be migrated to the new version as though it was a completely different CMS. Of course, it comes with a migration framework that is streamlined for precisely this purpose.  That said, the notion might give you pause, and reasonably so. Some things, like your theme (the site’s look and feel), won't migrate at all, and will have to be reengineered to leverage the benefits of Drupal 8.

Shelf-life

If you have a Drupal 6 site, you'll want to begin earnestly investigating a Drupal 7 upgrade now. Drupal 6 will have extended security support for three months after the official release of Drupal 8. When is that, exactly? Nobody really knows for sure. It depends on when there zero critical bugs left. As I’m writing this now, there are currently 54 critical issues. I'll wager that the last one will be completed in late spring, but, again, that's just a guess.

Update: as of April 16th, drupalreleasedate.com currently pegs the release date at September 30th, so I guess I was a little too optimistic!

Thinking even further down the road, figure that Drupal 7 will have three months of of support after the release of Drupal 9. So, extrapolating from the past, Drupal 7 should be supported by the security team until 2018. That’s not imminent by any means, but it will be here sooner than you think.

So, when it comes to building a new site right now, you have one of three options:

  1. Leap forward with Drupal 8
  2. Play it conservative and stick with Drupal 7
  3. Build on Backdrop CMS, a fork of Drupal 7

Drupal 8

The case for building on Drupal 8 now might seem obvious. After all, it is more powerful out-of-the-box than ever. It now comes, pre-rolled with key modules such as Views and a WYSIWYG editor, which previously took several additional months for a viable production release. Now, they are tightly integrated into Drupal core. This has the additional benefit of streamlining maintenance. That said, it is still early and there are other reasons to consider alternatives.
 

Drupal 7

There are currently 10,152 Drupal 7-compatible modules available on drupal.org and merely 673 for Drupal 8. That’s a vast difference. Drupal 7 has a mature ecosystem while Drupal 8 is in its infancy. For many sites, none of those missing modules are necessary. But for others, some are critical to its success.

Moreover, many of the core features in Drupal 8 are already available in Drupal 7: the Picture and Breakpoints modules provide support for responsive and retina image handling, the Mobile-friendly Navigation Toolbar, fieldable blocks (Bean), Admin Views for configurable administration screens, HTML5, … and more!

Of course, there are other improvements that are built into the foundation of Drupal 8, such as Symfony, that give it much more power to scale and decouple its components. If you are looking to serve content to mobile applications or an Angular front-end then there is probably little doubt that Drupal 8 is your platform of choice.

Yet, Drupal 7’s lifespan is limited and there’s no sense in building your site on yesterday’s technology when you are struggling to tread water. Enter Backdrop.
 

Backdrop

Recently, a group of developers in the Drupal community “forked” Drupal (7) onto a different development path. This new path is called Backdrop and will be a tempting option for many developers and site owners. The Backdrop community is small but very active and have incorporated some of the innovations of Drupal 8, such as an intuitive directory structure, while promising an indefinite upgrade path for Drupal 6 and 7 sites. If you are not interested in web services, decoupled architectures or complicated deployment workflows than Backdrop is worth a look.
 

Decisions

Which option makes the most sense for you? That all depends on your requirements and your time frame. It is an exciting time to be exploring Drupal.

The Isovera team is always available to help guide you through these issues based on your organizations technical and business needs. Reach out anytime if you have a project or initiative that you need guidance with.

Nov 09 2013
Nov 09

Here at Isovera, we manage quite a few Drupal sites. Many that we’ve built ourselves, soup-to-nuts so to speak, and plenty of others that we’ve inherited from other agencies or in-house teams. It is always interesting to see how other shops approach basic aspects of site building.

One of the first tasks you’ll encounter when building a Drupal site is setting up the first user account (UID1). We see it commonly given a username with some variation of "admin". This user account should be handled with care since it is supremely powerful, having all available site permissions. It is eqivalent to the root user or sudo (superuser do) command in the unix/linux world. If a malicious user is able to obtain access to this account, it’s ALL YOUR DATABASE ARE BELONG TO US time.

So access to UID1 should be guarded with care. Its use is really reserved for performing database updates and worst case troubleshooting. Routine site administration tasks such as adding users and moderating content should be performed with other user accounts. For this reason, we recommend using a clear username to distinguish UID 1 from other administrative roles. My preferred username for UID 1 is superuser. Another option mentioned earlier is root, but this connotes access to a directory structure, not permissions, which isn’t as relevant. In any case, I’m not alone in preferring superuser, as a casual google search confirms.

So now that UID 1 is done, we move along and create some additional user accounts to work on the site. To simplify the development process, out-of-the-box Drupal creates an Administrator role that conveniently has access to every permission on the site. While that’s quite handy when configuring URL alias patterns and accessing devel output, it’s often not appropropriate for routine administrative tasks. Sound familiar? Once again, it makese sense to override Drupal’s default naming conventions and change the administrator role to developer. On some occasions, I’ve found myself disabling the built-in “Administrator role” feature entirely, since I specifically don’t want certain permissions assigned to the developer role.

For better or worse, out-of-the-box Drupal tends to assume that the site administrator is also the site builder. While this developer-centricity endears Drupal to us developers, it can be confusing and even dangerous on larger projects. Fortunately, Drupal is flexible and easily changed to suit these needs.

Update: we now recommend appending a random string to the UID 1 account to obscure access to this critical account, for example, "superuser-?4LRHWZ8+D". This username might not be short, but the superuser prefix is descriptive to other users and it's sufficently random to thwart a concerted attack on your site.

Jun 13 2013
Jun 13

One of the more memorable moments from DrupalCon last month was the keynote by Karen McGrane. It’s a thrilling and motivating speech, but the point that probably stood out most was McGrane’s dismissal of the Spark inline editing initiative as something that was “ginned up by marketing”. Personally, I wasn’t surprised, since she had expressed her feelings about inline editing back in November on Lullabot’s excellent Insert Content Here podcast. But I think many attendees were taken by surprise, including, Dries Buytaert, the founder of Drupal and Acquia.

I base this hunch on Buytaert’s recent blog post, which took clear, almost wounded, umbrage at this remark. Acquia, for good reason, is, no doubt, proud of their success at getting Spark into Drupal 8 core. This was no small achievement. If I recall correctly, Buytaert championed inline editing as a goal for Drupal back in 2011, and for good reason. Content editors have struggled with Drupal’s modal user interface since the beginning.

Content à la Mode

I should probably clarify what I mean by modal. When working with content, Drupal displays two tabs: View and Edit. By default, after clicking the edit tab, the user is whisked away to the administrative theme, which is distinctively spartan and linear in comparison to how site visitors see the content. There is no mistaking that this is the edit mode. After submitting, or navigating away, the regular theme reappears and the view mode1 returns.

Some text editing applications also use a modal interface. Vim is an example of a modal text editor. Personally, I prefer emacs, which is modeless.2 There’s something to be said for the ability to immediately and seamlessly insert or edit text as you are reading it. There is less work and frustration than having to ceaselessly toggle between modes. And less friction means less subconscious resistance, which means more and better content. So, I understand the attraction to inline editing. It isn’t just marketing hype, it solves a real usability challenge.

McGrane’s concern is that cross-channel publishing, responsive design and the rapid flux of display technologies have exploded the digital metaphor of the printed page. And, instead of dispelling content creators of this illusion, Drupal 8 core will reinforce this vestigial metaphor by providing an inline editing mode and built-in WYSIWYG editor that privilege the desktop web browser because that’s where content editors get their work done.

Instead, McGrane argues that Drupal’s developers should be inventing new approaches and technologies that compel content creators to understand semantic markup and visualize the wider display possibilities of their words and media. One example she cites elsewhere, is a rendering interface that previews content in a desktop web, mobile web and app. But, mostly, we are left to our imaginations for answers.

Content Lifecycles

First of all, I think the criticism of Spark inline editing is overblown. The inline editor mode only appears when content is being edited and is irrelevant during the creation of content. This means that Drupal 8 users are exposed to the full edit mode fielded user interface whenever they create new content, even if they always use inline editing for existing content. So, unless they are happy recycling their finite supply of nodes, post-launch, they will at some point, have to reconcile themselves to working through a fielded form replete with structures and metadata.

Secondly, projects have finite lifespans. The content of some websites just doesn’t need to be abstract enough to easily reorganize and re-render in any conceivable future device. Drupal site builders have to find this balance for every project. Budget constraints always impose a limit to abstraction and automation. At some point, a page or block text area instead of a dynamically generated list is going to be good enough. And good enough is beautiful. Some websites just aren’t meant to be browsed on the refrigerators of flying cars.

The Here and Now

The preview button may be dead, but It’s not clear that user interface design alone can cure this desktop myopia. It’s one thing to evangelize for the future of Internet publishing, but we are faced with the work of building websites today and tomorrow. Our work is filled with budgets, compromises and exigency. We have to prioritize website features. We have to collaborate with content editors to build appropriate structures and train them on their usage.

Ultimately, I don’t think this an either/or decision. I think inline editing and well-structured, semantic markup are solid ideas and we can have both.

For a more in-depth look at the trade-offs involved with inline editing, be sure to checkout Jeff Eaton's awesome blog post, Inline Editing and the Cost of Leaky Abstractions.

1. There are actually six view modes (Full content, Teaser, RSS, Search Result, Search Index, and Tokens) bundled in core. Wouldn’t it be interesting if Drupal also came bundled with multiple edit modes?

2. While writing this blog post, I discovered that there is a modal version of emacs.

Apr 25 2012
Apr 25

Since the appearance of Drupal 5, Drupal distributions have been a steadily growing option in the world of Drupal development. A distribution is a prepackaged copy of Drupal core along with a premixed recipe of additional modules, themes, libraries, features and install profile scripts. When you install a copy of Drupal, you basically get a pre-built blogging application. When you install a Drupal distribution such as Open Atrium, you will have a full-fledged open-source project management application.

Currently, Drupal.org hosts just over 200 unique distributions that range from the breadth of federal government agencies, to news publishers, to language-oriented distributions, all the way to the highly specific niche of a local Baha’i community bulletin board.

Peeking under the hood

In the root of every Drupal directory is a folder called “profiles”. This profiles folder is where all of the files related to a distribution reside, right along side a “default” folder that contains Drupal core’s default install profile. An “install profile” is just a bunch of configuration functions that can enable modules, create user roles, build content types and set other kinds of system variables. A distribution consists of an install profile, plus all of the additional contributed or custom modules, themes and libraries. The default install profile, by the way, is where your basic page and article content types come from when you install Drupal from scratch.

Accelerating the development process…

We recently developed and launched a super innovative new online community for our client, PR market leader - Cision.  The online community, dubbed “Seek or Shout”, is geared for PR professionals, journalists, and bloggers looking for content, expert sources, research, and other support for stories. 

When planning the "Seek or Shout" project, we carefully weighed the costs and benefits of beginning the site from scratch versus building on top of the Acquia’s Drupal Commons distribution. There were good reasons to go either way. Commons didn’t yet have a Drupal 7-compatible release, which meant that users and taxonomy terms would not be treated as first-class entities. Also, Commons makes extensive use of Organic Groups modules, which provided functionality outside of the scope of the project’s design. On the other hand, Commons’ implementation of activity streams, user relationships and email digests were pretty close to our requirements. Ultimately, Commons won and we were able to simply use the content profile module to add fields to our user objects and suppress the Organic Groups module suite without any hiccups.

In retrospect, Commons gave us an unexpected boost when it came to the activity stream integration. This capability came with the activity log module, which can be downloaded a la carte.  But we discovered that a large amount of work was necessary to configure the rules module to respond to user activity and generate activity log entries or emails dependent on user relationships, interest tags and other criteria. Although the activity log module is generously documented, we would have been left scratching our heads without the contextualized work and features supplied by Drupal Commons.

Standing on the shoulders of giants

Whether a particular distribution is right for your needs is a complicated question.  Fortunately, it is no more difficult to install and explore a Drupal distribution than to install a plain vanilla Drupal site.  Since there are literally thousands of modules and themes to choose from, distributions produced by leading Drupal-focused firms are helpful guides in the challenging process of selecting contributed code for your Drupal site.  Distrubutions like Acquia's Drupal Commons are a bellwether for industry best practices.  Perusing a distribution is an easy way to get ideas for your own Drupal site, whether you use the distribution or not.  And that's where the beauty of open source software really shines.

Dec 22 2011
Dec 22

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.

 Screenshot of block visibitly settings

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.

Screenshot of Context module conditions

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!

Screenshot of Context module reactions

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.

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web