I'm just starting a responsive theme based on Omega, concentrating on the mobile layout at first.

There are certain blocks that will probably be deemed too 'heavy' to include on the mobile layout, and other blocks that will need to be introduced specifically for that layout (watered-down menus, toned-down user-bar etc).

I could easily hide the unwanted blocks on the mobile layout with CSS, and include the mobile-specific blocks on the default layout and hide those (so they're only shown for mobile), but that seems like quite a backwards way of thinking about it. If the blocks aren't shown, the extra overhead they incur would really be unacceptable (especially considering the number of extra db queries that the content in hidden blocks would add).

I'm thinking there must be a nice clean way to intercept the block decision-making process early on in the page build, and exclude/include blocks based on some os-detection, but I'm drawing a blank on how that might be possible.

I'm also going to throw in the fact that Varnish is running in front of this site, which should make things more fun :)

Are there modules/known strategies out there that can help with this?

I should add that using the Context module isn't an option as the site is already fully-fledged, and moving it into Context would be a massive undertaking at this point.

  • 4
    I would without question have used Panels and a relevant user-agent access plugin. Context could probably do the same, but as you already said, that's not an option. There's of course the horrible possibility of eval:ing the block visibility, but... On the other hand, with Varnish up front, the extra db-queries these block perform, might not be much of an issue?
    – Letharion
    Nov 21, 2012 at 19:54
  • @Letharion Yeah that's the thinking, let Varnish remove the strain. The site has a few hundred thousand active users though, and Varnish only gets involved for anonymous traffic. We'll be playing with ESI fairly soon but even then I can think of problems...from an SEO point of view the extra markup/menus would be heavy and potentially confusing, not to mention the extra (unnecessary) weight on pages for mobile users. It's a tough one!
    – Clive
    Nov 21, 2012 at 20:03
  • 1
    Perhaps add a more intelligent block handler (Panels/Context/other) to the heaviest pages, so you can get some gain from it without needing to redo the entire site?
    – Letharion
    Nov 21, 2012 at 20:16
  • 1
    I disagree that it makes the question stupid, or a total game changer. Varnish can be configured to handle the problem nicely, it just won't know how with an out of the box configuration.
    – Letharion
    Nov 23, 2012 at 9:26
  • 2
    @Clive : there's an old saying: "There is no such thing as a stupid question, only a stupid answer!" ;-)
    – AjitS
    Nov 28, 2012 at 11:06

4 Answers 4


intercept the block decision-making process early on in the page build, and exclude/include blocks based on some os-detection

Varnish is running in front of this site

As noted in the comments already, this requires you to configure varnish to not cache only on the request URL, but also vary on the user-agent. There is a relevant example in the varnish wiki, VCLExampleNormalizeUserAgent.

Once the request actually does hit the site, you need to determine which blocks to show and not to show. I would consider it no less than a disaster to do this with eval, so the most common options left then are Context and Panels.

With the site already built. redoing all pages/block placement with either module is probably not an option, but with a profiler, and applying 80-20, it could be possible to make significant performance gains by redoing specific pages only.

  • That's really really interesting thanks. The site in question is on Pantheon so I don't think configuring Varnish is an option, but this has turned into a more general 'how would one do this theoretically' type question now so this is very helpful
    – Clive
    Nov 23, 2012 at 9:31
  • Pantheon allows you setup STYXKEY cookies (towards the end of helpdesk.getpantheon.com/customer/portal/articles/425726 ) , and they allow you to segment what Varnish caches/serves for anon users.
    – Jimajamma
    Nov 26, 2012 at 21:37

I can't go into a lot of details, as I've not used either module for ages (I build all my sites with Context from the word go and I've not picked up responsive on something I haven't built for a while, so I've not had this problem before), but I think you should be able to put something together with Mobile Tools and Spaces.


Spaces is an API module intended to make configuration options generally avaliable only at the sitewide level to be configurable and overridden by individual "spaces" on a Drupal site. It has been described as:

  • A way to make one Drupal site act like several sites
  • A way to provide much more configurable, full-feature Organic Groups or user homepages
  • A generalized API for contextual configuration

Mobile Tools

The Mobile Tools module provides Drupal developers with some tools to assist in making adjustments to your site based on the visitor's device.

The project page for MT does say it's not ready for production though, which might be a problem - it depends when it was last updated, as the last commit was this month.




Browscap provides an improved version of PHP's get_browser() function.

Browscap block

Browscap Block adds visibility options to block configuration settings to allow you hide or show blocks in mobile devices.

Browscap does depend on your server setup, but if you can use it then the second module gives you extra visibility settings for each block on the block edit page.

enter image description here


you can use a jQuery cross browser support to get the screen resolution:

var browserWidth  = $(window).width();
var browserHeight = $(window).height();

Add simple PHP script to display setting of related block.

  • Thanks, but would that not mean converting the entire site to use AJAX for blocks? I'm looking to do this server-side if at all possible
    – Clive
    Nov 20, 2012 at 12:50

You could use Mobile Detect Block but I'm currently looking for a solution that works with window width and either AdaptiveTheme or Breakpoints module media queries so as not to duplicate that code and weigh down the end-user download any more than it is. I also had mixed results with Mobile Detect not picking up on one device I tested it with, which makes it rather useless like Browscap if it can't provide reliable results.

Some discussions have some people wanting to get away from Browscap for one reason or another, hence the move to Mobile Detect.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.