by David Burns on July 17, 2010 // Short URL

Assembling Pages with Drupal

Blocks vs. Context vs. Panels

As with many facets of Drupal, and coding in general, there are multiple ways to accomplish the same task. A good exmple of this was with the recent additions to the Lullabot team. The expanded team brought together three skilled developers and an amazing designer each with their own methods of site building. On one side we have Jerad Bitner and myself, who for the past few years have been building sites exclusively with Panels module. On the other side we have James Sansbury and Jared Ponchot who also build beautiful sites using the more recent Context module.

Our first collaboration was the redesign of, since this project was initially designed and scoped by James and Jared, the decision to use Context module was already in place. I was in no rush to learn Context, when I knew the same result could be achieved with Panels. Lucky for me James and Jared are both excellent resources for answering questions and giving great examples. Now that the project is complete I have a better understanding of Context module. This article is intended to identify the similarities, differences, pros and cons of using each module to build a Drupal website.

There is some overlap of terminology which will occur. A block is a block which can be used in both Context and Panels modules. Context is a stand alone module, but not the same as "context" that is used in Panels module. This will be clarified as you read the rest of this article. But before we travel too far down the rabbit hole, let's answer two basic questions:

What is a Page?
A page is HTML/JS/CSS rendered to the browser through a series of theme functions, hooks, preprocessors and template files.

How does Drupal build a page?
By making calls to menus, blocks, nodes, and modules, which then provide markup that will be placed into regions within the template system.


"Blocks are the boxes visible in the sidebar(s) regions of your Drupal website. Most of the blocks that you will see (e.g., recent forum topics) are generated on-the-fly by various Drupal modules, but you can also create your own blocks." ~

The Block system that comes with Drupal core has been around since Dec 2000, back when Drupal was just a baby. Since that time it has undergone many revisions and improvements. Today, modules can provide their own blocks by invoking hook_block(). These blocks can then be configured on the block administration page. A block can then be placed into a single region per theme and have it's visibility set by path, the current logged-in user's role, or custom which involves PHP logic that will return TRUE (enabled) or FALSE (disabled). For a number of websites this is enough options to accomplish most layouts, but as you gain expertise and work on more complex sites you begin to see the limitations of only having a single region to place a block within a theme. It's also worth mentioning that using custom and executing PHP from the database is very bad practice and could potentially be a security risk.


"Context allows you to manage contextual conditions and reactions for different portions of your site... Think of conditions as a set of rules that are checked during page load to see what context is active. Any reactions that are associated with active contexts are then fired." ~

I like to refer to Context as "The Advanced Page Builder". This is the block system on steroids, but even that is an understatement. Context module, created by the awesome team at Development Seed, lets you manipulate and activate items from the menu, block, module and theme systems using a robust set of conditions. Multiple conditions (or rules) can be set per context and multiple contexts can be set per page. Sounds confusing but hopefully a brief use case and diagram will help clarify.

Context 1:
Condition - Current node is of type "Blog" and user viewing blog has a role of "Admin".
Reaction - Display Admin Block in Left Column. Display a view list block of all nodes by current node author in Left Column.

Context 2:
Condition - Current node has taxonomy "Tech"
Reaction - Display a view list block of all Blogs that have a "Tech" taxonomy in the Left Column. Set Active menu item to "Tech".

Before a page is rendered, all of the context for a page will be called. If the current user logged in viewing this blog node has the "Admin" role, Context 1 and Context 2 will both exist, the resulting output of this page will have Admin Block, view list block of all nodes by current node author, and a view list of all Blogs that have a "Tech" taxonomy displayed in the region "Left Column" and the Active menu item will be "Tech". If the current user does not have the "Admin" role, only Context 2 will be true resulting in a view list of all Blogs that have a "Tech" taxonomy displayed in "Left Column" region and Active menu item will be "Tech".

context example

Due to this ability to mix, match, and stack context per page you have the ability to place not just blocks, but also views (provided by Views module) and menus into various regions within a page. In comparison, the core block system limits a block to only appear in a single region per theme with constrained visibility rules. This is great for site builders who can conceptualize sections of a site into specific context that will be needed to put together an entire site. However, this is not really great for handing a site over to a client who is expecting to modify page layouts without first explaining how Context module works. Another limitation of Context is that it's limited to the regions provided by the template system. The default regions available will be those provided by the theme. Context module allows you to provide your own template files which can add more regions and unique page layout.


"The Panels module allows a site administrator to create customized layouts for multiple uses. At its core it is a drag and drop content manager that lets you visually design a layout and place content within that layout." ~

I like to refer to Panels as "The visual Page Builder". If you are familiar with the tabbed navigation of Views 2, then you will be familiar with the navigation of Panels 3. The reason for this similarity is that both modules are the brain child of Earl Miles (merlinofchaos). Views and Panels work very well together because of this. At it's core, Panels is a drag and drop interface for placing content into sections on a page. This is attractive to most site builders because it sounds easy, and if you're just dropping in blocks or views then for the most part it is simple to use.

Panels is path driven. When creating a panel page you must declare a path. This path is what will invoke panels module to take over the rendering of the content area the page. This also means that Panels module can "hijack" the rendering of paths provided by Drupal core and other modules. As an example, let's say you enable Panels to render the output for 'node/%'. Once enabled you won't notice much of a difference when viewing the node, but if you look at the page source you'll see that there are divs with IDs and Classes which identify Panel panes.

Panes are regions within panels in which content can be placed. Panels provide a number of layouts (templates) that come shipped by default, they include 1, 2, 3 column, stacked or bricked. Another option for layout is Flexible, which allows you to build very complex layouts using a JavaScript UI without the need of creating custom template files. However, if you're more comfortable using custom template files that is also an option. Panels also provides you with the option to disable all sidebars provided by the theme, thus giving you further control of the rendered page.

So back to our example of using Panels to render 'node/%', and we've decided upon a layout (example: 2 column). How do we change the layout for a different content type? This is actually pretty simple. Each Panel you create allows you to have "Variants". Variants use selection rules that will trigger a specific panel display. Our default for all 'node/%' will be 2 column, but we can create a variant for node type Blog which can have an entirely different layout with entirely different content displayed in panes.

Aside from being a great way to change layout and position content on a page, Panels is a powerful tool that makes all content aware of each other. Since Panels is a wrapper that pulls in objects before rendering html to the screen, it has the ability to pass information about a block, node, or view to other objects within the panel. This is what Panels calls "context" (not to be confused with Context module). To build upon our original example of using 'node/%' as our Panel display, we then have the ability to pass anything (cck fields, author info, relationships, taxonomy, flag counts) from the node, into a view being rendered in the same panel!


Performance is important for any site (just stating the obvious). Whether it's a high traffic site spread across multiple servers or a small site on shared hosting, making the best use of resources available to deliver pages to your user faster gives a better user experience. With that said Drupal has a great caching mechanism built into core that, when enabled, provides significant improvements. However, the core block system is not as efficient at pulling in content compared to Context or Panels.

The core block system loops through block_list() for each template region and selects all active blocks in that block for current user. It then checks that block to see if it's enabled for current path or validates custom PHP rule. To use an analogy, think of an audience and a stage (which works well at DrupalCamp), and think of each member of the audience as a block. All members of the audience raise their hand if their first name starts with "A" (select region). The audience members with their hands raised keep their hands up if they consider themselves a themer (select active). Those remaining come up to the stage but put yourself in alphabetical order based on last name (sort delta). Repeat this process for each letter of the alphabet (each region). You can see this isn't exactly efficient.

Context is a vast improvement over the block system. After creating a set of conditions (rules) and reactions (display) via the Context UI (a replacement to the Block Admin page) this information is stored. When the page object is being built before being passed into theme functions it identifies which context currently exist and adds the context reaction (block, menu, views, etc.) to the page. Continuing the audience analogy, select 2 separate groups (context 1 and context 2) of people (reactions) at random and tell them where they would stand on stage. Clarify that not everyone on stage is a block, some can be a view or active menu item. I tell them context 2 no longer exist, the people in that group would leave the stage. This is much more efficient than looping through each region and checking for active blocks.

Panels has a bad wrap for being inefficient. I've know developers brought into projects to strip out Panels to improve performance. Let me publicly state that Panels is NOT the cause of slow loading pages. Inefficient and uncached queries used within views and blocks (both custom and provided by other modules) pulled into a Panel cause long page loads. Creating complex pages by stacking multiple inefficient blocks, views, and tabbed displays into a page will increase page load times drastically. However, the maintainers of Panels noticed this and have built in an incredible caching system that let's you cache individual panes inside a panel display. As stated before Panels is simply a wrapper that calls content into a page. Using the audience example one last time, I pick and choose the members I want from the audience and tell them exactly where to stand on stage. That's it, it's done. Panels is fast and direct.

With all that being said, there's other more efficient ways to address server performance, like apache/mysql tweaking, reverse cache, memcache and/or CDN for static files. Some of these advanced performance techiques are impossible to achieve on shared hosting environments. You get what you pay for.

Use Case

For many new users and simple site builders, using blocks is enough to get the job done. If the job gets done quickly and correctly, isn't that all that should matter? Stick with what works.

For more advanced projects that have complex layouts or require all changes to exist in code (exportable) then you'll need to use Context or Panels. Exportables are extremely important because it keeps all changes in code. This makes it very easy to develop in a local->dev->stg/qa->live environment. It also saves some time if someone makes a change that breaks the site or layout. Exportables make it very easy to revert, even more so if using a version control system.

Context is great for developers, not so great for end users. The abstract model of context requires a strong understanding of the project and which context will need to be created to achieve the desired output. It is much easier to understand Context UI than Panels UI. Context UI is more dynamic at putting together page variants by the way it allows multiple contexts to be declared based upon what's rendered on the page. However, it's also limited at passing information within a piece of rendered content to other content that exists on the page. By adding jQuery UI and Admin module Context module can provide a drag and drop UI for adding content onto an existing page. This is an excellent feature that brings it's usability closer to the drag-n-drop ability of Panels.

Context UI

Panels is great for site builders, and if there were a simple mode (less options) for the UI it would be great for end users as well. As it stands the nice drag and drop interface works well, but once you get into the configuration options of Panels, things get confusing for those new to it. These issues are being addressed with upcoming Panels 3. It's also good for non-developer site builders that are familiar with argument handling (from views module) to create a robust page with content that is all related. To me this is the biggest benefit and underused part of Panels. I could go on for two days about all of the awesome features of Panels, but that'll need to be in a separate article.

panels UI


The ultimate goal here and with Drupal in general is to allow site builders to build robust sites with related content without the need to get into code. As you can see Context and Panels modules do very similar task with very different approaches. But what is important to all of us is that they provide a solution. There was a minor disturbance in the force (aka our community) seeing two vital groups of developers addressing a similar issues without collaborating. Well good news, this year at DrupalCon San Francisco, these bright individuals were forced into a small room to settle their differences. By the end of this meeting there were hugs and tears of joy (okay, maybe just hugs).

What does this mean for Drupal? It means that the power of context, the ability for content on a page to be more dynamic and share information between each other will be an initiative that hopefully we will see built into a future release of Drupal core. Our modules can tap into a context api which will be full of valuable information about the user, node, views, blocks, and menus that exist within the page. This is huge. This is important. This is what keeps Drupal ahead of all other Open Source Content Management Systems.

David Burns

Senior Developer

Want David Burns to speak at your event? Contact us with the details and we’ll be in touch soon.



Great write-up

This is an awesome article that should be linked to from both the Panels and the Contexts project page. Thank you for this.

I am using Panels and I really needed a good introduction to Contexts. It seems to me that using both on the same side shouldn't be a problem. Or do Panels and Contexts interfere badly?

I really don't like the core Block system and not ALL of my pages is displayed by Panels. So it seems natural to use Contexts AND Panels. I am going to experiment with this.

You really seem to be a heavy Panels user and I hereby officially beg for a good article about the argument usage with Panels. This awesome module is underdocumented and especially this amazing feature. I am just wrapping my head around the argument features but a really good article with some examples would be great. I guess that a good part of the Panels user base does not use arguments because they don't really understand how to use this feature.

Looking forward to your upcoming articles.



Context and Panels

A lot of people ask me about using Context and Panels on the same site. I personally feel the tools are available inside Panels to get the job done, so I avoid adding another layer of complexity to a site. Also Panels has the ability to disable regions, so for any panel page that has this enabled it would be impossible to make good use of Context module. So while it's possible I tend to tell people it's not a good idea.

I agree a well documented article on Panels is needed. Thank you for the suggestion.



Context + Panels

Of course when most of a site is constructed via Panels Context is not really needed. I did some more thinking for a personal project and noticed that I tend NOT to use the Panels Node display for reason I am no longer sure of. So my idea was to use context on none Panel pages when most of those really could be constructed with Panels.

I am an absolute fan of Node Display though and might have to investigate how well Panels and ND play together (ie putting a ND into a Panels Page...). Time to play around I guess.


Chuck Vose

Panels + Context

In a recent project we tried running both Content and Panels and while some things worked great it was pretty obvious that there were some pretty big problems. The fundamental point is that Context makes Blocks powerful, Panels seeks to do away with Blocks entirely. There's even a checkbox to make sure Blocks don't act on your Page at all.

So if you're looking to do things with layout in Context it's not going to mix well with Panels, on the other hand, if you're looking to provide some flexibility for conditions that couldn't be achieved through Panels alone (such as, am I in a node that's the child of a translated resource) then you may be able to use both at the same time to great profit.




We use Panels for almost everything these days. It's awesome, especially when you start making your own layouts (which is really easy - I need to write a blog post about that). Just a quick note about the old Block system. Surprised you didn't mention Boxes. Exportable blocks ftw! (I guess with Panels you should use Mini Panels instead of Blocks or Boxes and maybe - if you're brave - disable block.module completely. But with Contexts I would think Boxes becomes an essential companion?)

Here's what I'm talking about:

And here's converting all your old Blocks to Boxes:


Tom James

Awesome overview


First up thanks for this is a great overview.
I've started to use context & panels on nearly all my projects and I absolutely love them especially for client sites.

One major question mark I had was their performance so to read that context & panels have decent performance is great news!

When I first saw the demo for context I wondered how much longer panels would be around for but having used both together I think they compliment each other quite well, although there does seem to be some overlap in functionality.

Thanks again


Patrick Connolly

Great Article!

Don't consider myself an expert on either yet, but just wanted to chime in with my thank you for the amazing article. On that note, how about some Like buttons on these articles? They need some Facebook social plugin love :)



I don't think Panels and

I don't think Panels and Context are comparable. They're not intended to do the same job. Panels effectively allows you to create pages on your site with any layout you could possibly imagine, designed visually. Context lets you show or hide things on already existing pages in already existing regions.



Having built numerous sites

Having built numerous sites using one module or the other, and going into deep discussion about which one to use with the rest of the development team. The fact that these discussions even occurred proved that there's enough similarity between them. Panels Everywhere and Context Layout, further shows even more overlap between these modules.

Though I agree the approach that each of these modules take to add or alter items on the page are very different. Both are providing the ability to create more complex page layouts based upon a certain context, wether it be set by the path or an element on the page.



See, I think you're wrong to

See, I think you're wrong to have that discussion in that way though. Panels is basically a visual way to create page templates. Yes, it has its own context system. Context is basically a visual way to show or hide blocks without modifying the page layout. Yes, it has a way to switch between predefined layouts. But their ultimate purpose is not the same.

At the end of the day, Panels should switch to using Context for its context system, and Context should drop Context Layout. But for now, which one you use should depend on what your need is, since their intended use is not identical even if they can often be used for similar purposes.



No, Panels is a content

No, Panels is a content collecting & rendering system, which also happens to provide an interface which allows you to create page templates. To reduce it to being just the frontend is to seriously misunderstand Panels - and it's the only way you could get away with a generalization like "Panels should switch to using Context." The only place where true functional overlap exists is in the Page Manager system of variants and selection rules - that's the thing that's actually similar to the 'reaction' concept in Context. However that Page Manager system is just something that _uses_ the underlying context system, it isn't the context system, which is actually a data wrapper on contextual information. And there's massive architectures built around that conceptualization of context, and they're not going away anytime soon.

While there are a number of ways in which we could bring the modules closer together, I'm mostly looking to the D8 Butler efforts as the place where we'll really see how that happens.


Steve Truesdale

Display Suite?

Excellent writeup - this helps to clarify many things. Such a comparison of page generation approaches helps me to get my head around how drupal does things in general.

Do you have any knowledge of how Display Suite would compare? It seems to be yet another way to generate the layout on a page - but more oriented around the layout and display of a particular node - kind of like Panel Nodes?

How would this fit with an entire page being generated by Panels or Context? Or would it not?

I'm trying to grok these options in order to determine when to use which ones. It would be very helpful to have a high level architectural comparison of these various page layout options (Panels vs Context vs Display Suite vs Skinr vs ???) - and the place filled by each.



I had heard about Display

I had heard about Display Suite awhile back, remembered that it look promising but had been so involved with Panels I never went back to try it out again. It was mentioned recently during a brain dump session as a possible fit for one of our internal projects. If you know any sites that have been built using Display Suite or good tutorial videos, please post a link here.



Display suite

Display suite works more upstream than panels and context. It's really powerful for doing quick basic outlining on nodes (like making a 2 or 3 column layout from a node display).

Using block fields you can pass information from a node or a view you are working with into the block that will be added to the display of the view or block. Especially on nodes this gives you a great deal of extra power.

For one project we needed to show an image with some data from a node that was referenced inside that node's content area. With display suite this is fairly straightforward.


Wim Mostrey


Another thing panels and context have in common is that neither really supports i18n very well, making both of them less suitable for multilingual sites.



context 3

Context 3 has the possibility to turn the context activation into an AND instead of an OR. We used this with great success on a multi-locale project where each locale had different block settings (e.g. French French and Belgian French) using a language condition and than the actual context condition we wanted to use.

So context is great with internationalization, you'll just have to make a bit more contexts.


Brian Nelson

Which tool for which job

Okay -- they can mostly do the same thing but there are times when you MUST use panels to do something or your MUST use context. Or there could be times when one tools is the better choice.

It seems panels is activated only off a path. Without the right path it won't function. Whereas context is activated by many other conditions besides just a path. (Not sure if path is a condition for context.)

It's also important to note that context has plug-ins that create additional conditions and reactions. Does panels have plugins and can panels be easily extended?

Another feature of context is that it can be used with the feature and spaces module. This is the basis for open atrium.

I love panels for layout but it may fall short in other ways. I have come to like how context when combined with features and spaces creates unique packaged capabilities.

I would like to see more comment on which tool for which job. This article seems to leave the impression that either will work but during the discussion there must have been some key differences identified and why did development seed go to all the trouble creating it?

Look forward to comments from others.


Damien McKenna

Panels has so much more..

Panels, with CTools, is so much more than just a basic layout engine. It provides structures to clearly have a hierarchy of layouts based on different conditions which allows you to have a default condition and then fine-tune a hierarchy as needed. Take for example the taxonomy integration, you can have a default panel layout, add ones for a few of your vocabularies, and then override a few more by specific terms. Further, with each panel you can override settings of other objects that are shown on the page (panes) beyond just selecting which ones to show. Lastly, thanks to being based on CTools, Panels has a huge API structure to work from which allows for very powerful plugins, style configurations, etc, etc.



Panels performance

You failed to mention that Panels allows you to export your layout to code and therefore decrease the load to the DB when deploying a site to production.

As others have said, there's not much point in comparing Panels to Context. Panels builds on CTools which is a swiss army knife of tools for site building. It all boils down to the price you're willing to pay in terms of time investment.

Panels has a steeper learning curve but the payout is much, much greater IMHO.


Victor Kane

Great must read writeup!

However, the limitations of the Drupal core block rendering system are not sufficiently stated: not only is the selection logic bad, as you very clearly state; but also all valid blocks are completely rendered on every single page before the selection is made, according to both Sam Boyer and Earl Miles DrupalCon SF presentations and as stated also in the great Lullabot podcast on this subject. So, assuming this is true, Panels Everywhere has a great advantage in circumventing this.


moshe weitzman

not any more

I think this was true in drupal 5 but fixed in drupal 6. it might be fixed only in 7, but i think its all good in 6.



i think i hemmed and hawed

i think i hemmed and hawed about it in the presentation because i wasn't 100% sure (read: haven't verified it myself), but the talk i've heard bandied around is that the fix was proposed for d6 and ultimately rejected.


bruce dou

The problem is how to track

The problem is how to track the configuration. Since code is easy to track using SVN or git. But how to record the process of the configuration is difficult. And the deployment always take me about 1 day or so.
Could you share the experience about these?



features module!

Check out features module. It lets you export db configurations to code which you can check into svn/git and then import onto your production environment. It supports things like contexts, panels, views, node types, permissions, and imagecache sizes, so it makes deploys a snap.



What did you use for this

What did you use for this ( site then?

Looking at the code I would guess you used Context with some custom layouts (for Ideas or Front pages).

The thing I don't like about Panels is that creating a layout does take you some time and you cant really have a default layout in "Panels everywhere" concept.

I am guessing you just have to make a decision what you will use and then master the tool!