Block caching with pagers

Drupal 6 and future core versions come with block caching. There are several constants you can set to determine how it is cached from none to per page, per role etc which then can hugely improve the performance on your site for both anonymous and authenticated users. But the cache also needs to be rebuild when there has been a total wipe of the page and block cache. Per page caching is an interesting one, but in some use cases leads to a lot of entries which you sometimes don't need.

An example: with faceted search (either with Apache Solr or with the Faceted search module), you can put a block in a sidebar giving you a list of facets to browse through results. Setting caching per page makes sense because the block contents will change depending on the facet you have clicked on. However, what with pagers ? The block will always have the same facet list, but will have a cache entry for each block because request_uri() will be different. We can avoid that one by having our own logic in a custom block.

This implementation exposes a new block and we deliberately set the cache to BLOCK_NO_CACHE because we will do our own logic in the function that will return the content of the block.

<?php
/**
* Implementation of hook_block().
*/
function test_block($op = 'list', $delta = 0, $edit = array()) {
  if (
$op == 'list') {
    return array(
     
0 => array(
       
'info' => 'Block cache per page with pager',
       
'cache' => BLOCK_NO_CACHE,
      ),
    );
  }
  elseif (
$op == 'view' && $delta == 0) {
    return
test_block_view();
  }
}
?>

The function that returns the content will use request_uri() and parse_url() to get the path that's requested and we will use that path as our own cache_id. We simply ignore all queries that might be available in the URI because we know that the block may have the same content for every page, despite any queries. This is a simple example, but you can add more logic depending on your use case of course. We store our entries in the cache_block table because that table is flushed enough so we don't have stale data on our pages.

<?php
/**
* Block callback.
*/
function test_block_view() {
 
$block = array();

 

// Get the URI without any query parameter.
 
$uri = parse_url(request_uri());
 
$cache_id = $uri['path'];

 

// Do we have something in cache ?
 
if ($cache = cache_get($cache_id, 'cache_block')) {
   
$block = $cache->data;
  }
 
// Otherwhise rebuild and cache it.
 
else {
   
$views_data = module_invoke('views', 'block', 'view', 'frontpage-block_1');
   
$block['subject'] = 'Frontpage';
   
$block['content'] = $views_data['content'];
   
cache_set($cache_id, $block, 'cache_block');
  }

  return

$block;
}
?>

Moving on and out

It's been a few weeks now since I sold my house where I've lived for 7 years, pretty amazing since I have this internal clock which forces me turn around stuff in my life every 3 years. Who knows if that changed too .. Anyway, I'll be homeless from the beginning of august if I don't start looking around for a new place to spent the next x years of my life - or at least sleep now and then. If you happen to know something around Gent, drop me a note, I'll be very interested to come and take a look if it's me-worthy.

Despite some rumours, I'm not moving out of the country - yet - New York will have to wait for a few years before I settle myself over there. And with the elections coming up, I might be moving to another country faster than expected .. :)

Topics 

personal

Hide the users icon in administration menu

I'm a huge fan of Administration menu, even more than projects like admin, toolbar or possibly others out there. If you want to delete some items from the menu, you need to implement hook_menu_link_alter() and reset the $item. Following snippets removes the users icon which shows the number of anonymous and authenticated users. Simple and powerfull.

<?php
/**
* Implementation of hook_menu_link_alter().
*/
function swentel_menu_link_alter(&$item, $menu) {
  if (
$item['title'] == 'icon_users') {
   
$item = NULL;
  }
}
?>

Drupalcon San Francisco and Display Suite


Due to Volcano activity on Iceland, I wasn't able to get to San Francisco for the biannual DrupalCon fest. But the Drupal community is that enthousiastic that we are setting up our own DrupalVolCon parties in Europe, already going on in London, Paris and in Antwerp. I'm supposed to give a session about Display Suite on wednesday, and that still might happen: we're busy testing and setting up streaming servers so we are able to stream our presentation on the internet at the time our sessions should take place in SF. All looks fine for now, so take that Eyjafjallajökull!

If you want to attend the session in Belgium, more info is available on http://belgium.drupalvolcon.com/

Update: we recorded the session and it's now available also on vimeo. Slides are at the bottom.

Display Suite profile

Related to our presentation, we just created a Display Suite profile containing all modules which are supported by Display Suite. We don't enable all modules by default in the installation profile, we just wanted to package them all, so you know what's possible.

We also packaged the Nodeform Columns module which enables you to organise your node forms in an easy way. If you don't really care about fieldgroups on the node form page, but need them on the front-end, you don't need to enable fieldgroups from CCK. The same applies to the tabs and cck fieldgroup tabs module, which are also included in the profile. Display Suite has this functionality by default.

You can see the full list of modules at http://drupal.org/node/775524, together with downloads of the profile and the packaged version of all modules with or without Drupal core included.

Important: some modules (like gmap and location) require the dev version to work properly, but for obvious reasons, the packed profile only contains official releases.

Anyway, sad I'm not there, but we're having fun here also!

Display Suite 1.1 'Fieldgroups baby'

After 2 months of hard work, we're proud to present you a new stable release of Display Suite and two new modules implementing the API, User displays and Views displays. A list of new features and bugfixes is available on the release notes of DS 6.x-1.1, make sure to read them as we had to introduce 2 small API changes. If you choose to upgrade, make sure you upgrade all other implementations too. A summary of cool new features:

  • Support for fieldgroups: the number one feature request by many users. You don't necessarily have to enable the fieldgroups module which comes with CCK, you can create as many as you like with the DS API via the interface. As a bonus, when the tabs module is enabled, you can change the output of your fieldgroups to tabs.
  • User Displays: first release which has support for the core profile module. Theming of the user profile finally got nice, especially in combination with fieldgroups support.
  • Views Displays: drag and drop your views, also with support for the Views attach module.
  • Region to block plugin: exposes regions per content type and build mode to a block.
  • Various other small new features like adding styles, simple panels support, location/gmap and syncing and copying display settings from one build mode to another.

New screencasts are available showing the new features and our demo site is also still available.

The roadmap has been updated, next focus is creating a full working version for Drupal 7. In the meantime, enjoy and see you hopefully at Drupalcon for our session about Display Suite!

Pages

Subscribe to realize.be RSS