Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Oct 17 2020
Oct 17
Drupal 8 will be released on November 19 | Wunderkraut


We're ready to celebrate and build (even more) amazing Drupal 8 websites. 
On November 19 we'll put our Drupal 8 websites in the spotlight...be sure to come back and check out our website.


Michèle Weisz


Want to know more?

Contact us today

or call us +32 (0)3 298 69 98

© 2015 Wunderkraut Benelux

Oct 17 2020
Oct 17
77 of us are going | Wunderkraut

Drupalcon 2015

People from across the globe who use, develop, design and support the Drupal platform will be brought together during a full week dedicated to networking, Drupal 8 and sharing and growing Drupal skills.

As we have active hiring plans we’ve decided that this year’s approach should have a focus on meeting people who might want to work for Wunderkraut and getting Drupal 8 out into the world.
As Signature Supporting Partner we wanted as much people as possible to attend the event. We managed to get 77 Wunderkrauts on the plane to Barcelona!  From Belgium alone we have an attendance of 17 people.
The majority of our developers will be participating in sprints (a get-together for focused development work on a Drupal project) giving all they got together with all other contributors at DrupalCon.

We look forward to an active DrupalCon week.  
If you're at DrupalCon and feel like talking to us. Just look for the folks with Wunderkraut carrot t-shirts or give Jo a call at his cell phone +32 476 945 176.


Related Blog Posts

Want to know more?

Contact us today

or call us +32 (0)3 298 69 98

© 2015 Wunderkraut Benelux

Oct 17 2020
Oct 17
Watch our epic Drupal 8 promo video | Wunderkraut

How Wunderkraut feels about Drupal 8

Drupal 8 is coming and everyone is sprinting hard to get it over the finish line. To boost contributor morale we’ve made a motivational Drupal 8 video that will get them into the zone and tackling those last critical issues in no time.

[embedded content]


Related Blog Posts

Want to know more?

Contact us today

or call us +32 (0)3 298 69 98

© 2015 Wunderkraut Benelux

Oct 17 2020
Oct 17

Once again Heritage day was a huge succes.

About 400 000 visitors visited Flanders monuments and heritage sites last Sunday.  The Open Monumentendag website received more than double the amount of last year's visitors.

Visitors to the website organised their day out by using the powerful search tool we built that allowed them to search for activities and sights at their desired location.  Not only could they search by location (province, zip code, city name, km range) but also by activity type, keywords, category and accessibility.  Each search request being added as a (removable) filter for finding the perfect activity.

By clicking on the heart icon, next to each activity, a favorite list was drawn up.  Ready for printing and taking along as route map.

Our support team monitored the website making sure visitors had a great digital experience for a good start to the day's activities.

Did you experience the ease of use of the Open Monumentendag website?  Are you curious about the know-how we applied for this project?  Read our Open Monumentendag case.

Oct 17 2020
Oct 17
Very proud to be a part of it | Wunderkraut

Breaking ground as Drupal's first Signature Supporting Partner

Drupal Association Executive Director Holly Ross is thrilled that Wunderkraut is joining as first and says: "Their support for the Association and the project is, and has always been, top-notch. This is another great expression of how much Wunderkraut believes in the incredible work our community does."

As Drupal Signature Supporting Partner we commit ourselves to advancing the Drupal project and empowering the Drupal community.  We're very proud to be a part of it as we enjoy contributing to the Drupal ecosystem (especially when we can be quircky and fun as CEO Vesa Palmu states).

Our contribution allowed the Drupal Association to:

  • Complete Drupal.org's D7 upgrade - now they can enhance new features
  • Hired a full engineering team committed to improving Drupal.org infrastructure
  • Set the roadmap for Drupal.org success.

First signaturepartner announcement in Drupal Newsletter


Michèle Weisz


Related Blog Posts

Want to know more?

Contact us today

or call us +32 (0)3 298 69 98

© 2015 Wunderkraut Benelux

Oct 17 2020
Oct 17

But in this post I'd like to talk about one of the disadvantages that here at Wunderkraut we pay close attention to.

A consequence of the ability to build features in more than one way is that it's difficult to predict how different people interact (or want to interact) with them. As a result, companies end up delivering solutions to their clients that although seem perfect, turn out, in time, to be less than ideal and sometimes outright counterproductive. 

Great communication with the client and interest in their problems goes a long way towards minimising this effect. But sometimes clients realise that certain implementations are not perfect and could be made better. And when that happens, we are there to listen, adapt and reshape future solutions by taking into account these experiences. 

One such recent example involved the use of a certain WYSIWYG library from our toolkit on a client website. Content editors were initially happy with the implementation before they actually started using it to the full extent. Problems began to emerge, leading to editors spending way more time than they should have performing editing tasks. The client signalled this problem to us which we then proceed to correct by replacing said library. This resulted in our client becoming happier with the solution, much more productive and less frustrated with their experience on their site. 

We learned an important lesson in this process and we started using that new library on other sites as well. Polling our other clients on the performance of the new library revealed that indeed it was a good change to make. 

Oct 17 2020
Oct 17

A few years ago most of the requests started with : "Dear Wunderkraut, we want to build a new website and ... "  - nowadays we are addressed as "Dear Wunderkraut, we have x websites in Drupal and are very happy with that, but we are now looking for a reliable partner to support & host ... ".

By the year 2011 Drupal had been around for just about 10 years. It was growing and changing at a fast pace. More and more websites were being built with it. Increasing numbers of people were requesting help and support with their website. And though there were a number of companies flourishing in Drupal business, few considered specific Drupal support an interesting market segment. Throughout 2011 Wunderkraut Benelux (formerly known as Krimson) was tinkering with the idea of offering support, but it was only when Drupal newbie Jurgen Verhasselt arrived at the company in 2012 that the idea really took shape.

Before his arrival, six different people, all with different profiles, were handling customer support in a weekly rotation system. This worked poorly. A developer trying to get his own job done plus deal with a customer issue at the same time was getting neither job done properly. Tickets got lost or forgotten, customers felt frustrated and problems were not always fixed. We knew we could do better. The job required uninterrupted dedication and constant follow-up.

That’s where Jurgen came in the picture. After years of day job experience in the graphic sector and nights spent on Drupal he came to work at Wunderkraut and seized the opportunity to dedicate himself entirely to Drupal support. Within a couple of weeks his coworkers had handed over all their cases. They were relieved, he was excited! And most importantly, our customers were being assisted on a constant and reliable basis.

By the end of 2012 the first important change was brought about, i.e. to have Jurgen work closely with colleague Stijn Vanden Brande, our Sys Admin. This team of two ensured that many of the problems that arose could be solved extremely efficiently. Wunderkraut being the hosting party as well as the Drupal party means that no needless discussions with the hosting took place and moreover, the hosting environment was well-known. This meant we could find solutions with little loss of time, as we know that time is an important factor when a customer is under pressure to deliver.

In the course of 2013 our support system went from a well-meaning but improvised attempt to help customers in need to a fully qualified division within our company. What changed? We decided to classify customer support issues into: questions, incidents/problems and change requests and incorporated ITIL based best practices. In this way we created a dedicated Service Desk which acts as a Single Point of Contact after Warranty. This enabled us to offer clearly differing support models based on the diverse needs of our customers (more details about this here). In addition, we adopted customer support software and industry standard monitoring tools. We’ve been improving ever since, thanks to the large amount of input we receive from our trusted customers. Since 2013, Danny and Tim have joined our superb support squad and we’re looking to grow more in the months to come.

When customers call us for support we do quite a bit more than just fix the problem at hand. Foremostly, we listen carefully and double check everything to ensure that we understand him or her correctly. This helps to take the edge off the huge pressure our customer may be experiencing. After which, we have a list of do’s and don’t for valuable support.

  • Do a quick scan of possible causes by getting a clear understanding of the symptoms
  • Do look for the cause of course, but also assess possible quick-fixes and workarounds to give yourself time to solve the underlying issue
  • Do check if it’s a pebkac
  • and finally, do test everything within the realm of reason.

The most basic don’t that we swear by is:

  • never, ever apply changes to the foundation of a project.
  • Support never covers a problem that takes more than two days to fix. At that point we escalate to development.

We are so dedicated to offering superior support to customers that on explicit request, we cater to our customers’ customers. Needless to say, our commitment in support has yielded remarkable  results and plenty of customer satisfaction (which makes us happy, too)

Oct 17 2020
Oct 17

If your website is running Drupal 6, chances are it’s between 3 and 6 years old now, and once Drupal 8 comes out. Support for Drupal 6 will drop. Luckily the support window has recently been prolonged for another 3 months after Drupal 8 comes out. But still,  that leaves you only a small window of time to migrate to the latest and greatest. But why would you? 

There are many great things about Drupal 8 that will have something for everyone to love, but that should not be the only reason why you would need an upgrade. It is not the tool itself that will magically improve the traffic to your site, neither convert its users to start buying more stuff, it’s how you use the tool.  

So if your site is running Drupal 6 and hasn’t had large improvements in the last years it might be time to investigate if it needs a major overhaul to be up to par with the competition. If that’s the case, think about brand, concept, design, UX and all of that first to understand how your site should work and what it should look like, only then we can understand if a choice needs to be made to go for Drupal 7 or Drupal 8.  

If your site is still running well you might not even need to upgrade! Although community support for Drupal 6 will end a few months after Drupal 8 release, we will continue to support Drupal 6 sites and work with you to fix any security issues we encounter and collaborate with the Drupal Security Team to provide patches.

My rule of thumb is that if your site uses only core Drupal and a small set of contributed modules, it’s ok to build a new website on Drupal 8 once it comes out. But if you have a complex website running on many contributed and custom modules it might be better to wait a few months maybe a year until all becomes stable. 

Oct 17 2020
Oct 17

So how does customer journey mapping work?

In this somewhat simplified example, we map the customer journey of somebody signing up for an online course. If you want to follow along with your own use case, pick an important target audience and a customer journey that you know is problematic for the customer.

1. Plot the customer steps in the journey

customer journey map 1

Write down the series of steps a client takes to complete this journey. For example “requests brochure”, “receives brochure”, “visits the website for more information”, etc. Put each step on a coloured sticky note.

2. Define the interactions with your organisation

customer journey map 2

Next, for each step, determine which people and groups the customer interacts with, like the marketing department, copywriter and designer, customer service agent, etc. Do the same for all objects and systems that the client encounters, like the brochure, website and email messages. You’ve now mapped out all people, groups, systems and objects that the customer interacts with during this particular journey.

3. Draw the line

customer journey map 3

Draw a line under the sticky notes. Everything above the line is “on stage”, visible to your customers.

4. Map what happens behind the curtains

customer journey map 4

Now we’ll plot the backstage parts. Use sticky notes of a different color and collect the persons, groups, actions, objects and systems that support the on stage part of the journey. In this example these would be the marketing team that produces the prod brochure, the printer, the mail delivery partner, web site content team, IT departments, etc. This backstage part is usually more complex than the on stage part.

5. How do people feel about this?

Customer journey map 5

Now we get to the crucial part. Mark the parts that work well from the perspective of the person interacting with it with green dots. Mark the parts where people start to feel unhappy with yellow dots. Mark the parts where people get really frustrated with red. What you’ll probably see now is that your client starts to feel unhappy much sooner than employees or partners. It could well be that on the inside people are perfectly happy with how things work while the customer gets frustrated.

What does this give you?

Through this process you can immediately start discovering and solving customer experience issues because you now have:

  • A user centred perspective on your entire service/product offering
  • A good view on opportunities for innovation and improvement
  • Clarity about which parts of the organisation can be made responsible to produce those improvements
  • In a shareable format that is easy to understand

Mapping your customer journey is an important first step towards customer centred thinking and acting. The challenge is learning to see things from your customers perspective and that's exactly what a customer journey map enables you to do. Based on the opportunities you identified from the customer journey map, you’ll want to start integrating the multitude of digital channels, tools and technology already in use into a cohesive platform. In short: A platform for digital experience management! That's our topic for our next post.

Oct 17 2020
Oct 17

In combination with the FacetAPI module, which allows you to easily configure a block or a pane with facet links, we created a page displaying search results containing contact type content and a facets block on the left hand side to narrow down those results.

One of the struggles with FacetAPI are the URLs of the individual facets. While Drupal turns the ugly GET 'q' parameter into a clean URLs, FacetAPI just concatenates any extra query parameters which leads to Real Ugly Paths. The FacetAPI Pretty Paths module tries to change that by rewriting those into human friendly URLs.

Our challenge involved altering the paths generated by the facets, but with a slight twist.

Due to the projects architecture, we were forced to replace the full view mode of a node of the bundle type "contact" with a single search result based on the nid of the visited node. This was a cheap way to avoid duplicating functionality and wasting precious time. We used the CTools custom page manager to take over the node/% page and added a variant which is triggered by a selection rule based on the bundle type. The variant itself doesn't use the panels renderer but redirects the visitor to the Solr page passing the nid as an extra argument with the URL. This resulted in a path like this: /contacts?contact=1234.

With this snippet, the contact query parameter is passed to Solr which yields the exact result we need.

 * Implements hook_apachesolr_query_alter().
function myproject_apachesolr_query_alter($query) {
  if (!empty($_GET['contact'])) {
    $query->addFilter('entity_id', $_GET['contact']);

The result page with our single search result still contains facets in a sidebar. Moreover, the URLs of those facets looked like this: /contacts?contact=1234&f[0]=im_field_myfield..... Now we faced a new problem. The ?contact=1234 part was conflicting with the rest of the search query. This resulted in an empty result page, whenever our single search result, node 1234, didn't match with the rest of the search query! So, we had to alter the paths of the individual facets, to make them look like this: /contacts?f[0]=im_field_myfield.

This is how I approached the problem.

If you look carefully in the API documentation, you won't find any hooks that allow you to directly alter the URLs of the facets. Gutting the FacetAPI module is quite daunting. I started looking for undocumented hooks, but quickly abandoned that approach. Then, I realised that FacetAPI Pretty Paths actually does what we wanted: alter the paths of the facets to make them look, well, pretty! I just had to figure out how it worked and emulate its behaviour in our own module.

Turns out that most of the facet generating functionality is contained in a set of adaptable, loosely coupled, extensible classes registered as CTools plugin handlers. Great! This means that I just had to find the relevant class and override those methods with our custom logic while extending.

Facet URLs are generated by classes extending the abstract FacetapiUrlProcessor class. The FacetapiUrlProcessorStandard extends and implements the base class and already does all of the heavy lifting, so I decided to take it from there. I just had to create a new class, implement the right methods and register it as a plugin. In the folder of my custom module, I created a new folder plugins/facetapi containing a new file called url_processor_myproject.inc. This is my class:

 * @file
 * A custom URL processor for cancer.

 * Extension of FacetapiUrlProcessor.
class FacetapiUrlProcessorMyProject extends FacetapiUrlProcessorStandard {

   * Overrides FacetapiUrlProcessorStandard::normalizeParams().
   * Strips the "q" and "page" variables from the params array.
   * Custom: Strips the 'contact' variable from the params array too
  public function normalizeParams(array $params, $filter_key = 'f') {
    return drupal_get_query_parameters($params, array('q', 'page', 'contact'));


I registered my new URL Processor by implementing hook_facetapi_url_processors in the myproject.module file.

 * Implements hook_facetapi_url_processors().
function myproject_facetapi_url_processors() {
  return array(
    'myproject' => array(
      'handler' => array(
        'label' => t('MyProject'),
        'class' => 'FacetapiUrlProcessorMyProject',

I also included the .inc file in the myproject.info file:

files[] = plugins/facetapi/url_processor_myproject.inc

Now I had a new registered URL Processor handler. But I still needed to hook it up with the correct Solr searcher on which the FacetAPI relies to generate facets. hook_facetapi_searcher_info_alter allows you to override the searcher definition and tell the searcher to use your new custom URL processor rather than the standard URL processor. This is the implementation in myproject.module:

 * Implements hook_facetapi_search_info().
function myproject_facetapi_searcher_info_alter(array &$searcher_info) {
  foreach ($searcher_info as &$info) {
    $info['url processor'] = 'myproject';

After clearing the cache, the correct path was generated per facet. Great! Of course, the paths still don't look pretty and contain those way too visible and way too ugly query parameters. We could enable the FacetAPI Pretty Path module, but by implementing our own URL processor, FacetAPI Pretty Paths will cause a conflict since the searcher uses either one or the other class. Not both. One way to solve this problem would be to extend the FacetapiUrlProcessorPrettyPaths class, since it is derived from the same FacetapiUrlProcessorStandard base class, and override its normalizeParams() method.

But that's another story.

Mar 01 2013
Mar 01

Design builds on wireframes to create the right look and feel. Development uses them to understand what needs to be built. Make them too specific and designers will feel like they are only coloring in the boxes. For developers the drawings and annotations rarely provide enough detail to really know what to build.

The risk then is that neither get done well, resulting in generic wireframes that seem to go through the motions without really specifying anything in a useful level of detail. This does not stimulate collaboration across disciplines.

When the wireframes are not good enough, that usually means some other project parameters are not defined clearly enough.

What do you want to achieve?

Wireframes are too specific for answering some essential questions. Do you have a clear definition of why the site should exist in the first place? What will it accomplish for the business? Which user goals will it support? Without a solid vision for the product and its target audiences, how can you know what to put on the screen?

A clear set of prioritized business objectives and user goals makes it easier to decide wether a given feature should be built in the first place. Wireframes can’t capture this.

Specifiy interaction through interaction

Specifiying interaction with static images and words is hard. Suppose you have a small email signup form. Drawing and describing all possible variations will still not provide the necessary level of detail. Instead, build a working prototype. It will surface all the different states much faster.

Interactive prototypes are much better at demonstrating the flow of interaction across multiple screen states.

Making it work

More importantly, the not-good-enough wireframes are often only a symptom. When design and development are seperated in time, across multiple teams, you bet the wireframes won’t be good enough.

Development needs to be there when the concept is designed, to provide the necessary technical constraints. Design should be available to help fill in the blanks during development.

So, if the wireframes are not good enough, don’t just blame the wireframes. If you find the Why is not clear enough, look for the gaps in the project definition. Clarify the How with a clickable prototype. Collaborate across disciplines.

That’s why I’m excited to be working here at Wunderkraut. By designing for the user experience in parallel with an agile development team, we minimize the waste between design and build. By asking the difficult questions before diving into providing answers, we can focus on creating the best possible solution.

I look forward to working with you!

Sep 19 2012
Sep 19

While we were working on one of our upcoming projects, a new website for Stichting tegen Kanker, we had to integrate the Apache Solr module. We needed Solr for its faceted search capabilities. In combination with the FacetAPI module, which allows you to easily configure a block or a pane with facet links, we created a page displaying search results containing contact type content and a facets block on the left hand side to narrow down those results.

One of the struggles with FacetAPI are the URLs of the individual facets. While Drupal turns the ugly GET 'q' parameter into a clean URLs, FacetAPI just concatenates any extra query parameters which leads to Real Ugly Paths. The FacetAPI Pretty Paths module tries to change that by rewriting those into human friendly URLs.

Our challenge involved altering the paths generated by the facets, but with a slight twist.

Due to the projects architecture, we were forced to replace the full view mode of a node of the bundle type "contact" with a single search result based on the nid of the visited node. This was a cheap way to avoid duplicating functionality and wasting precious time. We used the CTools custom page manager to take over the node/% page and added a variant which is triggered by a selection rule based on the bundle type. The variant itself doesn't use the panels renderer but redirects the visitor to the Solr page passing the nid as an extra argument with the URL. This resulted in a path like this: /contacts?contact=1234.

With this snippet, the contact query parameter is passed to Solr which yields the exact result we need.

  1. /**
  2.  * Implements hook_apachesolr_query_alter().
  3.  */
  4. function myproject_apachesolr_query_alter($query) {
  5. if (!empty($_GET['contact'])) {
  6. $query->addFilter('entity_id', $_GET['contact']);
  7. }
  8. }

The result page with our single search result still contains facets in a sidebar. Moreover, the URLs of those facets looked like this: /contacts?contact=1234&f[0]=im_field_myfield..... Now we faced a new problem. The ?contact=1234 part was conflicting with the rest of the search query. This resulted in an empty result page, whenever our single search result, node 1234, didn't match with the rest of the search query! So, we had to alter the paths of the individual facets, to make them look like this: /contacts?f[0]=im_field_myfield.

This is how I approached the problem.

If you look carefully in the API documentation, you won't find any hooks that allow you to directly alter the URLs of the facets. Gutting the FacetAPI module is quite daunting. I started looking for undocumented hooks, but quickly abandoned that approach. Then, I realized that FacetAPI Pretty Paths actually does what we wanted: alter the paths of the facets to make them look, well, pretty! I just had to figure out how it worked and emulate its behaviour in our own module.

Turns out that most of the facet generating functionality is contained in a set of adaptable, loosely coupled, extensible classes registered as CTools plugin handlers. Great! This means that I just had to find the relevant class and override those methods with our custom logic while extending.

Facet URLs are generated by classes extending the abstract FacetapiUrlProcessor class. The FacetapiUrlProcessorStandard extends and implements the base class and already does all of the heavy lifting, so I decided to take it from there. I just had to create a new class, implement the right methods and register it as a plugin. In the folder of my custom module, I created a new folder plugins/facetapi containing a new file called url_processor_myproject.inc. This is my class:

  1. <?php
  3. /**
  4.  * @file
  5.  * A custom URL processor for cancer.
  6.  */
  8. /**
  9.  * Extension of FacetapiUrlProcessor.
  10.  */
  11. class FacetapiUrlProcessorMyProject extends FacetapiUrlProcessorStandard {
  13. /**
  14.   * Overrides FacetapiUrlProcessorStandard::normalizeParams().
  15.   *
  16.   * Strips the "q" and "page" variables from the params array.
  17.   * Custom: Strips the 'contact' variable from the params array too
  18.   */
  19. public function normalizeParams(array $params, $filter_key = 'f') {
  20. return drupal_get_query_parameters($params, array('q', 'page', 'contact'));
  21. }
  23. }

I registered my new URL Processor by implementing hook_facetapi_url_processors in the myproject.module file.

  1. /**
  2.  * Implements hook_facetapi_url_processors().
  3.  */
  4. function myproject_facetapi_url_processors() {
  5. return array(
  6. 'myproject' => array(
  7. 'handler' => array(
  8. 'label' => t('MyProject'),
  9. 'class' => 'FacetapiUrlProcessorMyProject',
  10. ),
  11. ),
  12. );
  13. }

I also included the .inc file in the myproject.info file:

  1. files[] = plugins/facetapi/url_processor_myproject.inc

Now I had a new registered URL Processor handler. But I still needed to hook it up with the correct Solr searcher on which the FacetAPI relies to generate facets. hook_facetapi_searcher_info_alter allows you to override the searcher definition and tell the searcher to use your new custom URL processor rather than the standard URL processor. This is the implementation in myproject.module:

  1. /**
  2.  * Implements hook_facetapi_search_info().
  3.  */
  4. function myproject_facetapi_searcher_info_alter(array &$searcher_info) {
  5. foreach ($searcher_info as &$info) {
  6. $info['url processor'] = 'myproject';
  7. }
  8. }

After clearing the cache, the correct path was generated per facet. Great! Of course, the paths still don't look pretty and contain those way too visible and way too ugly query parameters. We could enable the FacetAPI Pretty Path module, but by implementing our own URL processor, FacetAPI Pretty Paths will cause a conflict since the searcher uses either one or the other class. Not both. One way to solve this problem would be to extend the FacetapiUrlProcessorPrettyPaths class, since it is derived from the same FacetapiUrlProcessorStandard base class, and override its normalizeParams() method.

But that's another story.

Sep 14 2012
Sep 14

As this is the first time I went to a Drupalcon, I was amazed about the entire convention. The people of the community, the sessions, the location, the food, the after sessions evening/night life, … it all matched perfectly together. An amazingly well organised event, that's what it was.

Wunderkraut Day

By a lake in the Englischer Garten... 4 great European Drupal companies joined forces.
And I must say, wow! Seeing the 130 Wunderkraut people together, that does something to you. Especially considering the knowledge sharing, getting to know each other, open discussions. In the baking heat, we joined our new 130+ colleagues and were then split up in focus groups like Deployment, Sales and Front-End development. We discussed modules, processes, infrastructure, support and every other aspect of Drupal. It's heart warming how much talent and expertise the new Wunderkraut combines, which is evidently the whole point of the merger.

The merger was mentioned in the Program Guide, so everybody who registered on Monday knew what was going down. Twitter feeds lit up with the news, and once it's on Twitter, there's no turning back. Gimme that T-shirt. Let's turn Kraut.

Drupal development insights

During the open discussion I joined a group of developers. We discussed if we had install profiles and how we passed on our sites from developer to developer to frontender... For instance, the people of former NodeOne almost always use Nodestream (which uses Features, demo data, ...), where-as we use drush and Ctex, sometimes we use features. Mearra also uses features from the beginning, because it's good to enable and disable chunks of content. But features can get quite heavy when you have a big website.

Context, Panels, Display Suite and Panelizer

Then we went into a discussion about Context vs Panels (and Page Manager). We all agreed that we like using Panels more. We compared quite a few modules with each other. And things got really interesting when we started comparing Display Suite and Panelizer. Certain members don't use DS because it separates the logic of field structure and the display entirely, which makes it quite difficult to use in certain cases. Seeing as Swentel was part of our discussion group, he immediately responded and he said he'd get it fixed. Which made the 'getting together' even more great. Some threw problems on the table while others jumped up and gave their piece of mind about it. I think everybody learned from the whole experience./>


The caching preferences were quite clear. We all use Varnish to store cache. We load in the users and use cache actions. And the user specific caching per role is done before bootstraps by Varnish. For smaller sites entity caching is quite good, but it is too heavy for bigger websites. Boost together with Domain Access was frowned upon though.

Development environment

Development environments were a 'hard to get it right' issue for many. Getting all parties (developers and frontenders and ...) to have the same environment is a big issue. There were those who use VM (sharing + mounting tools), Vagerant (with puppet/chef) which controls a Virtual box, Debian virtual box together with whim, steel environment, the same laptop environment with shared databases with update scripts, ... A whole bunch of tools and use cases came to light here, yet no real 'winner' was chosen, everything has it's ups and downs.


Testing can also be a big scare/hard thing to do. The best thing to do probably is test driven development, yet it is not always done like it should. What really should be done is testing the code by peers before the site is set up for the client or before DOM.
You can reinstall a basic install profile using Simple Test, but bigger install profiles should be tested with SimpleTest Clone. A big plus to use is Features, it already tests the code while it is being made/adjusted. Unit testing is also a way to go. And there was a suggestion to use the browser called Zombie, it is good for testing javascript (in stead of selenium).


Multilingual websites can best use Entity translation (has views integration) and it handles fields and terms with the hook node/edit. While using taxonomy it is advised to use the module Title for translating the label and the description, entity translation can take care of the custom fields implemented here.

And now, back to the main event, Drupalcon Munich!

Security and Return on Investment

There is so much information that goes 'round during a Drupalcon. The first thing I was intrigued by was an item about Security. Drupal security is something that some analysts, PO's, themers and sometimes even developers forget about. Because everything is so straight forward in Drupal core, most things are considered as 'very safe' already. It is timeconsuming (at first) to implement this in the existing processes (if you haven't already) but considering the ROI, it is totally worth it.

Just think about the Linkedin password breach and nobody will argue with you about 'how time-consuming and yet worth it' it actually is. For instance, did you know that checkboxes don't have a security check but selectboxes do? So put this into consideration dear dev friends.

Drupal 8

The future is nay.. within a year or so. But today is the day that matters!
The thing about these Open Source gatherings is that they inspire you to start coding, they dare normal people to do big things and get them started on contributing and sharing with the masses.

Dries' keynote was in fact introduced by Captain Drupal and the announcement of the Wunderkraut merger, which was the biggest news at DrupalCon this year. Right next to Drupal 8 of course as laid out by Dries. There were lots of ooohs and aaahs, accompanied by vigorous applause.

For instance, Reflections DrupalCon Munich, Part I, talked about Drupal 8 and Symfony, which is a huge step forward. Drupal also has other items that makes the future even brighter, for example it's going to be integrating Twig, a template engine for PHP. Which makes it easier for themers to focus on the job at hand, instead of having to also focus on several php, security issues and whatnot.

Inspiring was the fact that quite a few modules are looking into the client satisfaction as well as the developer/site builder side of things. If modules take the 'easy to use for editors' into consideration, the step towards using Drupal is even smaller. Which makes it more appealing to all kinds of companies and thus creating a larger pool of contributors in the long run. That's something that the session about Commerce was all about, easy to use and out of the box functionalities.

An other highly appreciated item is the Multilingual features in D8. Even though they're still in search for contributors, the entire plan behind it is very promising. All entities will have a language setting, changing the default language of the installation shouldn't be a problem, uploaded documents and the search option will be subjected to language settings.

Also, a big cheer goes out to the block configuration settings. One block can be copied and changed to have different properties. Thus being able to have a sidebar block, containing 'Bars' and 'Foos', and having the same block in the footer, containing 'Bars', 'Pirates' and 'Ninjas'.

Seeing that Drupal is quite a stable and much used CMS, it now has time to focus on growth. It can focus on getting better, having more reusable features and overall known standards. That is what makes Open Source so great. Seeing a good working item, tearing it apart and making it into a new and better whole.

One of the best DrupalCons

The Drupal Association did an amazing job organising Drupalcon. It's incredible how fluid things went and how easy it was to get a cup of coffee when you desperately needed it. They deserve our support, so if you're not a member, become one today: https://association.drupal.org/membership

All in all, the program was solid, the venue was exquisite and the atmosphere was awesome! Until next year!

Sep 05 2012
Sep 05

DrupalCon Munich wrapped up one week ago. This was my fourth DrupalCon and a couple of things made it really stand out. So let's reflect back on what makes this such a great conference.

The organisation

DrupalCon Munich hosted 1800 Drupal enthusiasts, developers and business people spread out over two hotels. Because everyone was concentrated in one location, you had ample opportunity to bump into some like-minded soul during and after conference hours. Another benefit: we didn't lose a lot of time commuting between the venue and our hotel. The sessions and keynotes themselves were excellent. I learned a lot over these past days. Didn't attend this edition? Most sessions were recorded. You can revisit them at the DrupalCon website. Another kudos goes out to the catering. The food was excellent and plenty. The Organizing Committee did an outstanding job. A thorough understanding and experience is required to be able to organize an event of this scale. To me, a successful conference like this is a sign we are maturing as a community.

Wundernauts are great people

I wanted to work for Krimson because they value people, community and knowledge. And of course their projects. So, I was very happy to hear that we have merged with three other Drupal companies just as ambitious, talented and focussed. The new organisation will continue under the name Wunderkraut.

On Monday, the day before DrupalCon, we finally got to meet our new colleagues. Assembling 130 new coworkers from all over Europe is no small feat to pull off. This was an unique opportunity to exchange experiences. We spent the day having open spaces getting to know each other and learning from each other's processes through intensive discussions.

Merging is not easy. But I'm convinced we, Wundernauts have a really big opportunity of working together as a whole and creating a bright future for the company. All companies have Drupal in their DNA. The cultural similarities are striking. That should give us enough of a head start to provide top notch services.

Spreading knowledge to the outside is part of our identity. Now, we can also share knowledge and ideas with our coworkers over the whole of Europe.

The sessions

Of course, I attended a good deal of sessions. I've compiled the highlights and major themes of this edition.

Drupal 8 Configuration Management

I've spent more time in Drupal Core sessions than any other year. With the upcoming 8 installment of Drupal, there is a lot that's going to change. Drupal is growing up fast and it's becoming a fully functional and flexible framework consisting of a number of new and revamped subsystems. The system I'm really looking forward to is Drupal 8's improved Configuration Management.

The Configuration Management Initiative is geared toward tackling the challenge of pushing configuration between Drupal websites. With configuration we mean that part of the website's functionality which is stored in the database as blobs of settings. The same database which also holds the clients' content. The tight interlocking of configuration and content into the same store makes deploying new features, security updates and fixes a drudgery.

Fixing this problem is important as our projects grow in complexity and we are more meticulous about quality control. The improved Configuration Management Initiative (CMI) makes it easier to develop on one environment, push changes to the acceptance environment so the client can review, to finally end up in the production environment.

This is essential for continuous and faster release cycles. Something we all strive for.

Drupal 8 Web Services

Another initiative which I value highly is the WSCCI initiative. It aims to transform Drupal from a CMS heavily focussed on websites to a true Content Management Framework managing content not only for traditional websites but also client heavy interactive javascript web apps and mobile applications.

Basically, Drupal will act more like an open system to manage content which can be distributed all over the web. Content isn't confined to a website, but can also be exposed to the users through whole array of applications and devices. Since these new kinds of applications are becoming more commonplace, an efficient content management tool is essential. This means businesses can manage their content in one place for their website, android app or iPad application.

This change requires a radical change in architecture. To accommodate this, the initiative makes use of Symfony components which brings me to my last point.

Drupal is heading a new and better direction with Symfony

Symfony 2 is a fully stacked PHP web framework on one hand, and a set of reusable components on the other. The Drupal community decided to make use of these Symfony 2 components as it was taking on the challenge to take the system to the next level. There are a few good reasons to do this.

First and foremost, we don't want to reinvent the wheel. Rather then solve certain complicated problems again, we'd rather make use of existent sophisticated solutions provided by Symfony instead. This provese to be a huge timesaver.

Second, Symfony 2 components are written in elegant Object Oriented PHP as opposed to the prevalent procedural style of Drupal. This means Drupal is becoming more mainstream and familiar to non Drupal developers which will make it easier to bring new talent in the community. Companies might find it easier to find skilled Drupal developers.

Third, this change also brings new perspective in how code should be written which in turn will increase its' quality.

Fourth, we are not just using Symfony components, we are working together with the Symfony community to make them better and vice versa. This joining forces will strengthen our skills and knowledge.

Fifth, as our projects become bigger and bigger, sometimes they tend to lean more to the application side compared to pure Website Content Management. By using Symfony Components, we are better prepared to use the Symfony tools to tackle those problems. Basically we will have a richer toolset which will benefit certain types of projects.

Lastly, I perceive this as a sign we are maturing and getting wiser as a community and building a more robust product. As developers, we often think we should build everything ourselves. It takes courage to identify and use systems which are already optimized for a given problem set.

That we made such a decision as a community makes me believe we will make more of these wise decisions in the future strengthening our community and making Drupal a stronger product, increasing the value for our customers.


This edition of DrupalCon Munich was a blast. The organisation did a great job and gave everyone an outstanding experience. Of course, for us, we had the extra dimension of becoming Wundernauts and got a unique chance to hook up closely with fellow Drupalistas from all over Europe. Finally, the Drupal project is heading towards a bright future with new, exciting challenges.

Aug 22 2012
Aug 22

As the summer heat hits Europe, Drupal geeks gather for another edition of DrupalCon. The event takes place in Munich, Germany this time. Of course, the Krew, reinforced with new team members, attends the event, eager to gain new insights and share knowledge.

The news that Krimson, Mearra, NodeOne and Wunderkraut decided to join forces, was announced over the past two days. As Wunderkraut, the 140 coworkers aim to deliver measurable client happiness and business value. The entire team got together at an introductory meet up on Monday, well before the main event. As the day progressed, team members shared ideas, practices and solutions in a set of open spaces in the relaxed environment of one of the Münich city parks.

Krew member Nelia: “During the open discussion I joined the developer open space. As junior developer I learned a lot. A lot of useful information was shared and discussed between the backend developers. Because of the merge, we are confronted with different ways of working, but as we got along, we discovered that we shared a common view on most development practices and methodology.”

Krew member Jurgen: “As dedicated Support engineer I was faced with the challenge of finding the open space that worked for me, my area of work spans from front-end to system monitoring and everything in between. I joined the growing force of front-enders and later the System Administrators' open space where a lot of the Support tasks are being handled. It became apparent that across the board we all strive towards openness and processes that work in the long term so we can focus on doing what we love to do, delivering kick-ass Drupal products.”

The new Wunderkraut team ended the day with a few celebratory beers.

DrupalCon Munich opened its' first day with the ABC of DrupalCon, in traditional Bavarian style. As we were welcomed, we learned, amongst other things, how to jodel like a boss and what DrupalCon and the Drupal community is all about. Captain Drupal flew on the stage, in the style of a true superhero, announcing the Wunderkraut merger. It was quite an awesome sight to see all the Wunderkraut people wearing their brand new t-shirts, saying Hi to them when they pass by and sharing experiences and plotting the future. It shows the power of people working together under one brand, powered by the entire Drupal mindset.

The actual opening of the conference was, as always, the highly anticipated keynote by Dries (aka the Driesnote) Josh Koenig interviewed Dries about the state of Drupal.

Dries gave a preview of Drupal 8 showcasing such new features as inline content editing, import/export of configuration and mobile website administration (SPARK). Drupal 8 development is moving towards a feature freeze this december. The community is now looking forward to a release date set around this time next year. With Drupal entering new markets and going for enterprise business, large companies are getting involved with Drupal. This evolution introduces benefits, but also drawbacks to the Drupal project. In the end, when the market consolidates around 2 or 3 really big CMS'es - as it did with operating systems - Drupal ideally conquers itself a place among those.

DrupalCon schedules a wide variety of sessions. The Krew attended several of those. The new Entity and Property API in Drupal 8 session was presented to the attendees. Core developers Fago and Dixon_ ran a technical overview of the different API’s. The main goals of the revamped API’s are to improve the consistency of the logic, make fields fully translatable, improve the interoperability - which is important since D8 is geared towards services - and introduce standards in the data model and the code. The session draw to a close with a round of Q&A and a call to dig into the issue queue.

The Think like a hacker: Drupal security session taught Krew the finesses of building a website using secure code and best practices. Security is an important factor to think about during the entire development process. While it might present an overhead cost, everybody benefits in the long run since fixing security breaches are way more expensive once a leak has been exploited. During the session, we learned quite a few developer best practices such as using Drupal specific security functions in your code and always validate user input.

Drupal 8 is also going to come with a lot of changes at the theming layer. The Designer friendly theming system in Drupal 8 session explores these changes. Learning how to theme has always been difficult as the system comes with a steep learning curve. Front-end specialists are required to deal with the intricacies of PHP and the Drupal API. With the introduction of Twig, the community hopes to stow away most of that complexity, lowering the bar and aiming for simplicity and consistency. The development of the system is very much a work in progress, just as the Entity API, and the speakers invited everybody to join the code sprints which take place during the conference.

As the day came to a close, all the attendees gathered at the Biergarten am Chinesischer Turm having a great time, enjoying a fresh beer and typical Münicher dishes.

Jun 29 2012
Jun 29

I got annoyed by the mess on my laptop. Three years hence, its' hard disk has turned into an archive of stuff I've been working at some point or another. The vast majority ranges from fully fledged projects we maintain to half borked vanilla Drupal installations I once used to demo something to fully fledged. Over time, I changed employer a time or two and did some freelance stints. Each time, I had to adapt to new conventions, configurations, versioning tools and development setups.

In the end, the thing I *didn't* do well was managing my own development environment. I'm not talking about the technology I'm using (as it happens: I'm on a OSX using MAMP) but the way, or lack of, I kept order in the data I manage. Inevitably, you're development environment gets cluttered over time. If you're not very careful, you'll end up with stale databases, different versions of files, directories and dumps with no specific purpose, cryptic leftover configuration files,... In short: chaos. Why? There's only so much time, and at the end of the day, it's very easy to just wing it rather then clean up abandoned local projects. That's what happened to me.

So, I set forth to think how to improve this for myself. I've started using a set of common conventions each time I set up a new project. Most of them I picked up at Krimson. I decided to share them, here it goes:


  • Create a Workspace folder i.e. /home/you/workspace. All PHP files, applications, DB dumps,... should be stored here.
  • Group each project in it's own folder. i.e. /home/you/workspace/myproject. Of course, you might work for different clients or employers. Just prefix your folders: i.e. colada_project and krimson_project.
  • Each project has four basic subfolders: www/ which contains your document root, db/ which contains database dumps, docs/ which contains your development information (notes,...) and patches/ with specific drupal patches you might need when setting up that project.



  • Use virtual hosts. No exceptions. Putting each project in a subfolder of the documentroot so you can surf to http://localhost/myproject is bad practice since such setups require extra configuration in .htaccess. When you go live, you might end up doing mucking in your .htaccess. Or worse, discovering you have to change hardcoded URL's in your code if you were really careless!
  • Use a comprehensive local domainname. You could go for "myproject.dev" or "myproject.lan". I use "netsensei.myproject" for extra clarity. The first part could also refer to the hostname of my machine.
  • Each vhosts comes with its' own vconf file. In my MAMP, I have a separate folder called sites/ which contains a vhost configuration per project.
  • Each configuration file is called netsensei.myproject.conf.
  • Use a working template file for your configuration. Just copy and paste and alter when need to do so (you shouldn't on your own machine unless really needed!) This way, you'll avoid having to debug your configuration for the gazillionth time i.e. because the path to your logfiles contains an error.
  • Same goes for your /etc/hosts file: keep it clean! I try to keep all the entries alphabetically ordered so I can easily find an entry in the list.

Of course, you don't have to work with /etc/hosts and configuration files. You could also do a one time setup of a local BIND DNS server and let Apache do the heavy lifting for you. Check out this article on how to set up a smarter MAMP.


As a Drupal dev, I'm 99.9% of the time working with a MySQL setup. But these should serve for any db system really...

  • Never, ever use the root user to connect to your database from your project. Not even on your development machine. Why? It's a bad habit and mistakes are easily made. Moreover, if something goes really wrong, you don't want other projects to get messed up too.
  • Use the same name for your database as for your user. Ie. DEV_MYPROJECT. Each user only has privileges granted to that database.
  • Be consistent in how you name your user and database: always go for uppercase or lowercase. But don't intermingle. Keep things clear and simple.
  • I use the DEV_ prefix on my local machine. Why? When my PHPMyAdmin tool is open, I want to be pretty sure that's not a production database I just dropped.



You didn't install Drush? Shame! You should! Drush Makes developer life a breeze!

  • Use Drush aliases for every project you start! An alias file allows you to load and bootstrap Drupal from the command line from every location.
  • Each file is called netsensei.myproject.alias.drushrc.php

Those are a few conventions we try to live by. Of course, most of this is sheer repetition after a while. To avoid errors, we wanted to automate the process of setting up a project. A few years back, we worked with a set of shell scripts to get the job done. Over time, we converted our scripts to Drush commands. We couldn't share them because they were very Krimson specific, locked in our own workflow. A few months back, we started using Git. Integrating support in our tools turned out to be quite the hack. So I ventured out and created my own Drush toolset called Rum. It does two things:

Setting up a new local project starting from a vanilla Drupal core setup or setting up an existing project from a remote repository (Git or Subversion) honoring the above conventions.

Rum allows you to delete the entire project including the vhost configuration setup, database and reference in the host file.

This is strictly a aid for use in a development environment. Of course, this is just one way of doing things. These might be the right tool when you're working on your own but turn out to be contraproductive on an enterprise level where individual developers many more variables to take into account. There are other ways of setting up development environments which allow you to easily and safely sync. I highly recommend looking at Vagrant which allows you to rapidly setup and tear down custom tailored virtualized development environments per project. I would also recommend taking a look into the realm of DevOps, which is a fairly young field aiming to tear down the wall between developers and system operators, lowering the bar for deployment, maintenance, security,... in terms of efficiency and flexibility.

I presented Rum and my own setup as a BoF session at DrupalCampGent 2012 on May 26th. I've put my slides on Slideshare (Dutch)

Apr 20 2012
Apr 20

In a previous article, we already gave you a sneak peek of the upcoming changes for Display Suite. More than two months later and a lot of coding, the new branch is ready to start testing. In this article we'll highlight the biggest changes.

Menu structure and discoverability

The main task of Display Suite is simple: configuring the display of your content. For new users, it took a while before they understood how they could get that 2 column layout on their basic page because of two major problems:

  • The main menu entry point at admin/structure/ds leads you to another overview screen with, depending on other settings and/or enabled modules, new options. The main task, namely configuring that layout, was not even the first one. And it was cryptically named as ‘layout’.
  • On the “Manage display” screen, the vertical tab on the default view mode, which usually is the first one you click on, underneath the table wasn’t visible enough to give users the hint that they should choose a layout before the magic starts.

So we completely changed the menu structure for this. Clicking on Display Suite now leads directly to the overview of all available displays, with the most important one, namely, all content types available in your current Drupal website. Other functionality like fields and view modes have been converted to a menu tab.

Besides that, the layout tab is now always the first with some new enhancements as well.

Previews and default fields

Nothing feels better to actually know how your template looks like. In the past, the only way to for site builders to get a bit of a hint, was reading the descriptions in the select box carefully. Or worse, switching over and over until they found the exact layout they want. From now on, selecting a layout will show you a preview image of how the structure looks like. Ajax, oh, we love you. Changing a layout will also show you the previous and next state, so you can’t miss anymore. And it gets better: from now on, when first selecting a layout, default fields will be inserted into the first known region. Imagine you have already configured formatter settings of an image and the body: you will not lose them anymore after selecting a layout.

Configurable wrappers per layout

In Display Suite 7.x.1.x layouts and regions were traditionally wrapped inside a div. It was possible to choose a different wrapper for regions and the layout inside a template. This has several drawbacks.

  • You have to create your own custom templates in code
  • Each sets of wrappers needs a custom template.

To overcome this problem we decided to make the wrappers configurable in the user interface. This increases the flexibility of the layouts a lot. At this moment we support the following wrappers:

  • div
  • span
  • section
  • article
  • header
  • footer
  • aside

Sometimes a group of fields listed in a region doesn't belong to the same wrapper. You can group a set of fields inside one region with fieldgroup. As of today there is an HTML5 formatter for fieldgroup that provides the same HTML5 wrappers we added to Display Suite.

All these changes turn Display Suite into a flexible HTML5 layout builder. To make this possible we had to add more php code to the templates. But as a bonus, they now work on both display and form. If you want to create your own custom template it is advised to use the built in drush script.

  1. $ drush ds-build "Two regions" --regions="Region 1, Region 2"
  2. $ drush ds-build "Several regions and css" --css=1

Hide empty regions

We have removed the 'Hide empty region' checkbox. Instead, we ship with fluid and non fluid templates. The logic now happens inside the template to print or hide a region with or without content in it. This may seem dramatic, but it's actually a better way of working. Choose your layouts wisely now when configuring a display.

Field template settings

One of the hardest coding parts for this branch was moving the field template settings, an option in the Extras module, into the cogwheel on the right, instead of a link triggering a fake formatting screen. This benefits both frontend and backend performance, since we do not print all field template form elements for every field on the manage display screen. It’s now only loaded when configuring a single field. The 'expert' field template now has full control over the field template including (default) classes and attributes.

There are still some tiny problems with this conversion, but the basic functionality is working fine.

Alter before you print

While the layouts in combination of fields gives you great flexibility to decide which content should be printed, there are still use cases where you do want to override a configured layout just before it's sent out to the template file. This was impossible in DS 1, but we now introduced hook_ds_pre_render_alter so you can make any changes you have to. Add new fields, switch them in regions, add new regions .. you name it, it's all possible now.

Upgrade path

With all the changes we listed so far, we have decided to not support an upgrade path between both branches. It’s not that we want too, it's simply because we know for sure sites will break, especially with the changes on template level. We don't want you to reconfigure your site together. Both branches are still supported, however, new features will only go into the second branch. So for existing sites, keep using the first branch. For every new site, you can start using the second one - or wait at least for an official release.

Call for testers and coders

We expect to roll out at least one release candidate at the beginning of june and a full release at the end of june, maybe somewhere just after the Drupal Dev Days in Barcelona. We will test this ourselves extensively the next coming weeks, but we invite you to test along with us and report any bugs you might find. Patches are always better of course. There are 2 critical issues remaining in the queue which need special attention from both site builders and theme developers.

  • http://drupal.org/node/1536066: due to the changes in the template system, we still need to decide how themes, like the Mothership, should provide layouts that can work for both versions of Display Suite.
  • http://drupal.org/node/1519916: the cogwheel needs some fixes to not print out summaries for fields that aren’t allowed to use the field templates, e.g. preprocess fields. Consequently, the field template options can not be available either, but for some the label should remain.


We have plenty other subtle changes and a couple of new features. A full overview is available at http://drupal.org/node/1524800. However, a screencast is always better than words, so we recorded one for your viewing pleasure. Sit tight, grab some coffee and enjoy watching. The screencast is also embedded at the end of the post.

Thanks to all who helped

Usually, I don’t get so melodramatic, but sometimes thanking people can be fun, so here goes. I’d like to thank Bram "aspilicious" Goffings for accepting an internship at Krimson working almost full time during that period to get these changes rolling. He's also co-author of this post. Bojhan and Yoroy, our UX gatekeepers who assisted us in the issue queue with great screenshots, sketches and layouts. Pfrenssen, mrfelton and frega helping us out during the 3 days Easter Display Suite sprint. And last, but not least, Krimson for trusting me and jyve that this was worth doing. Maybe another last one: to all those 20K+ installations using our software. The steadily growth and feedback from everyone out there is what keeps me motivated to make this as good as possible!

We’re excited, we hope you will be as well!

Feb 23 2012
Feb 23

So, you’re a site builder and you want to manage the layout of a node, form, search result,... then Display Suite is a fantastic tool to get the job done through the user interface. Thus avoiding extra coding.

As with other great Drupal modules Display Suite started out as a small project. Over the course of a few years, Display Suite became a powerful and well known tool with more then 17.000 installations!
All that muscle doesn't come for free. Features got added like lego blocks with a working product as primary goal. Now it is time to look back and analyse the usability of Display Suite. Krimson gave me the opportunity to analyse and improve the UX of Display Suite as part of my internship.

UX improvements

I engaged in extensive discussions with themers, developers, designers and usability experts and charted the strengths and weaknesses of Display Suite from different perspectives. The fact that I had to explain basic functionality to some of them is a telling sign.

The current interface is too confusing. There is no separation between primary and secondary tasks, some operations are not understood or misunderstood by reading the help text, the naming of labels and menu's is inconsistent or unclear, several options are not to be found, ...

Based on these discussions I made several improvements in a new, separate feature branch of the project. You can get this version of Display Suite from the Git repositories. I also opened an issue in the Display Suite queue with more info about the proposed changes in the prototype.

Needs review

Before we can merge these, I call on site builders, themers, developers,... who are using or have used Display Suite. We need you to review and test the proposed changes so we can fix things before they get merged in. Even if you're not a Display Suite user this is a great opportunity to contribute to this powerful module.

The current branch is stable but should not be used in production sites yet. If you find a bug with the new branch or you don't like one of the changes please respond in the issue.

When you get stuck try to find me in one of the drupal IRC channels or ask for help in the issue mentioned above. It helps me and the community to understand the issue. Your input, doesn't matter how small it is, can bring Display Suite to a higher level.


I'm also highly involved with the drupal 8 HTML5 initiative. Over the past months I gained a lot of insights on the benefits and drawbacks of HTML5. During my Display Suite analysis I researched the posibilities to combine both. I implemented a solution that provides HTML5 wrappers for layouts, regions, subregions and fields. If you have another take on how we can foster integration of HTML5 and Display Suite, pleases share your ideas!

Feb 18 2012
Feb 18

Krimson hosted another Drupal User Group at its Ghent offices this week. The topic was CultuurNet, a client we have done multiple projects with in the recent past.

CultuurNet is an organization gathering all events happening in Flanders. It distributes those events over multiple websites targeted by location or target audience over multiple platforms (website, mobile website, iPhone, Android, ...).

To allow this, CultuurNet makes heavily usage of Drupal at different points in its architecture. In this showcase we show where this precisely is and how we created a reusable layer between all Drupal solutions to allow CultuurNet to launch new sites fast and cheap.

CultuurNet showcase
Aug 17 2011
Aug 17

The Krimson krew is totally prepared for the upcoming DrupalCon in London! Of course, we'll be presenting. On Tuesday 23rd August, Swentel and jyve will give a session about Display Suite for Drupal 7. They'll introduce you to a whole set of updated and new features which will make building websites a breeze. They'll also have a couple of surprises in store.


Yes, we like our Display Suite module that much, we felt it needed to have its' own t-shirt! We'll be wearing them (and maybe you too!) to show our love for Display Suite and Drupal.
We'll be handing them out to a lucky few at DrupalCon. Make sure you're attending one of our sessions to win one. And if you want them signed, well... just talk to us.

Display Suite Mini Booklet and Video's

Krimson will also be giving out a mini booklet about Display Suite. This handy pocket guide teaches the reader how to start theming like a boss with Display Suite in 11 easy steps.
Each part of the guide is accompanied by a video. We've recorded eleven screencasts showing you the power of Display Suite for Drupal 7. You can already watch them at http://bit.ly/ds-d7. In case we're out of booklets: take out your scissors, print the PDF version and start crafting your own booklet following a few simple instructions.

Display Suite booklet

So, the Krimson Krew hopes to meet you at Drupalcon London!

Jul 15 2011
Jul 15

Lately, I've been working on a Drupal project which involves Mailchimp integration. Mailchimp is an excellent service which manages all the monkeyjobs while you can send out newsletters to lists of subscribers carefree.

The service allows you to create a (or use a predefined) reusable template for your newsletter. You pass the content which needs to be sent out on a frequent (weekly? monthly?) basis to your subscribers to Mailchimp and it will churn out a new newsletter based on your template.

One of the requirements of the project is that a subscriber can opt in to receive a customized newsletter based on selected interest groups. The content of the newsletter are Drupal nodes that were published since the last edition of the newsletter. Using the taxonomy module, these nodes are assigned to one or more of the twelve available interest groups.

I need to aggregate the data in Drupal into digestible content and send it in a single Mailchimp campaign. There's a catch though: a campaign is send out to all users, not those that have opted in for interest groups x, y or z. So, how can you solve this?

Enter: smart merge tags with groups. Using Mailchimps' smart merge tags within the newsletter content generated by Drupal, I can target specific interest groups.

Like this:

  1. *|INTERESTED:Interests:Sports and entertainment|*
  2. Node Title B
  5. *|INTERESTED:Interests:Lifestyle|*
  6. Node Title A
  7. Node Title C

Depending on the interest groups a user is subscribed to, only the content relevant to him or her will be shown in the newsletter. Thus creating personalized newsletters. Pretty cool!

There are a few limitations though. Over the past two days, I've been sparring with the Mailchimp support desk (They've been great and very helpful!) about the usage of commas in group names. You could do something like this:

  1. *|INTERESTED:Interests:Sports and entertainment, lifestyle|*
  2. Node Title D
  3. Node Title E

Which will act as an OR filter showing content to people who are either subscribed to 'Sports and entertainment' or 'lifestyle'. But what if your group names themselves contain commas? What if you had a group called 'Sports, Culture and entertainment'. Well, Mailchimp will be confused and think these are two groups 'Sports' and 'Culture and entertainment'. Since those are nonexistent groups, the content won't show up at all. I've tried escaping the commas and putting everything between quotes: nothing works.

This is the solution provided by the Mailchimp people:

"Regarding the use of commas in a group name, we would recommend removing these commas if at all possible.

We have passed this issue onto our developers for investigation. At this time we do not have an estimated time frame of when we will be able to hear back from them. However, we will continue to investigate and push a resolution as soon as one becomes available if our developers do believe this to be necessary.

At this time, removing all commas from the group names and creating an ELSE statement would be our top ideas!"


Of course, you're probably eager to hear about the Drupal bit of my Mailchimp adventures. Well, stay tuned. I've been toying with the Mailchimp API. And I like it. A lot. I've chalked up a few ideas. I'm going to let them stew a little bit longer until I've got a clear head about what is feasible.

May 24 2011
May 24

From March 14th until May 10th, the Krimson dojo had two interns under its' roof. Yves Van Laer and Els Wens, both last year students at the Lessius Hogeschool Mechelen, were trained and guided by Roel De Meester, to become 'Krimson certified' Drupal ninjas in 8 weeks.

Their mission? Realizing a new website for the Belgian label Chicken Rhythm, specialized in a unique and colorful kids collection of T-shirts, rucksacks and iron-ons.

Chicken Rhythm currently consists of two separate websites: a webshop and a related blog. Krimson was asked to build a flexible and redesigned website integrating both. The overall aim was to improve the ease-of-use regarding maintenance and content management, adding a few new features and, of course, giving a new fun and fresh look.

Building the Chicken Rhythm site was a perfect case for our trainees to get an insight look in the project chain from A to Z: perform a bit of information architecture with the client, whip up some mockups, learn how to interpret wireframes, install and configure Drupal, perform some PHP coding, HTML/CSS markup and create a design (assisted by ninja Kristof Orts).

The realization of the website was also an appropriate case to explore and test the Drupal Commerce module, a professional e-commerce solution for Drupal 7. After thorough testing of the module, using it to build the webshop, our interns came to the conclusion that the current released version (7.x-1.0-beta3) is not (yet) sufficient for 'out of the box'-use.

They presented their findings at our krewmeeting. You can find their presentation at Slideshare [Sorry, only in Dutch].

There's still some work to be done on the site, before we'll launch it in the near future.

We wish our interns Yves and Els all the best with their future ventures!

Drupal Swag & certificate for our internsGift basket from our intern Els Wens

Thanks for the gift basket and home made ice cream!

Mar 08 2011
Mar 08

It’s the time of the year, all the Drupal geeks are packing their bags and getting ready for Drupalcon Chicago 2011. Unfortunatly not everyone is going to the windy city of Chicago. So the Krimson krew members that are staying here in Belgium, decided to organize 3 days of Drupal geekiness and work for the community.

Some of the cool stuff we’ll be working on will be Sweaver, module browser and other secret cool Drupal things.

We’re also streaming the keynotes live from Drupalcon Chicago. All the unfortunate people that got left behind are more then welcome to join us at the Krimson offices in Gent, with some beers and lots of Drupal fun!

Written byKristof Orts

The most remarkable thing about 'the' Krimson Graphic Designer and Adobe Specialist is that, during a briefing, you can't help but think that the kid didn't get a word of what you said. Then he quietly marches out of the room and returns before the deadline with a perfect reflection of your demands - but better, WAY better - the Eagle Eye For Detail. Which is why he was hired right after his internship. This ice hockey goalie catches pucks and bad guys, he melts slowly and so the Krew prepares for the day Kristof loses his cool.

Feb 10 2011
Feb 10

Hack all night, sleep all day - Drupal Dev Days

Here at Krimson, we've almost recovered from this weekends' Drupal Developer Days meeting in Brussels. Up until now, the yearly rendezvous between Drupal developers was part of the larger FOSDEM event, but this time, a separate, parallel event was organized to answer the growing demand for more knowledge from an expanding community.

This edition of the Drupal Developer Days became a downright hit. Somewhere between 400 – 500 Drupal enthousiasts from all over the world descended upon Brussels for a weekend of Drupal, catching up and beer.

As a Platinum sponsor and co-organisator of the event, the Krimson Krew was also present during the weekend volunteering and giving several presentations.

Our design ninja Kristof Orts gave a presentation on adaptive design systems for multiple devices. In his session, he pointed out that the web is much more then computersscreens. Tablets, smartphones,... they all connect to the web. And we developers and designers should work together, designing new ways to dynamically adapt and scale content to this variety of ways to display information.

Our own Roel Demeester presented From Zero to Hero with Drupal 7 in one hour. His introductory crashcourse session took beginners through the first steps of setting up their first Drupal 7 site and a overview of what you can do with Drupal.

Matthias Vandermaesen presented Riding the Semantic Web to the crowds, shedding light on the many mysteries that surround the SemWeb scene within Drupal. Giving a few demonstrations and presenting his work on SPARQL Views through the Archipel project which Krimson is involved in as a partner.

Videos of the sessions will be published on the event website.

Drupal Dev Days also provided extensive training sessions by Dataflow and Krimson. Wim Mostrey presented an introduction to module development on Saturday while Matthias Vandermaesen and Nascoms' Kristof Van Roy taught participants the basics of content visualization with Display Suite, Panels and Context modules on Sunday.

Of course, there was much more. The talk of Robert Douglass on Selling your code: the Drupal Appstore, Mortens' session on Designers vs. Developers and chx' Drupal 8, first things first spawned a lot of discussion on these hot topics over the weekend. The codesprint on Friday at the Emakina offices drew quite an interested crowd of developers working together tackling issues.

Next to the courses and presentation, we were also present with our (= Krimson + Dutch Open Projects) new initiative Drupal Pond, that aims at helping freelancers in working together on great high quality projects by exchanging knowledge and experience. More on that very soon...

We would like to thank all the sponsors and the participants for making Drupal Developer Days BXL '11 a huge success. Thank you! We hope to meet you again on a next edition.

Jan 25 2011
Jan 25

Here at krimson, we are working on our own super-duper start-theme. (Who's not, right?)
In that quest for our holy grail, I did find some interesting tips and tricks I want to share.

You've certainly heard about HTML5, and the new semantics this provides us.
If you haven't, have a look at the magnificent keynote from Jeremy Keith at Drupalcon Copenhagen, called 'The design of HTML5'.

At one brave day, I started to build a drupal theme, based on those new HTML5 elements.
Very soon, a problem became clear: older browsers don't support those new semantic tags.

The HTML5 boilerplate solves this by using modernizr, a javascript library to detect a browsers support for HTML elements.
On top of that, it also provides a way to make older browsers use elements like header, section, etc.

A quote from the modernizr website:

"Modernizr also adds support for styling and printing HTML5 elements. This allows you to use more semantic, forward-looking elements such as section, header and dialog without having to worry about them not working in Internet Explorer."

With the help of some clever javascript, modernizr creates those new elements in browsers that don't support them. Let's look at the technique used here:

  1. (function(){

  2. if (!/*@[email protected]*/0) return;

  3. var e = "abbr,article,aside,audio,bb,canvas,datagrid,datalist,details,dialog,eventsource,figure,footer,header,hgroup,mark,menu,meter,nav,output,progress,section,time,video".split(','),i=e.length;

  4. while (i--) {document.createElement(e[i])}})()

So here all elements are created by javascript, and when you actually use them in your CSS selectors, everything will work .... Until you turn off javascript!
This is where problems arise. Some statistics show that about 5% of all browsers don't have javascript capabilities or it is simple turned off.
Do we (or our clients) need to decide if we simply ignore those users? Should we wait until everyone is migrated to more modern browsers?

The million dollar question....
I personally don't like that idea. I think we should work with the tools that are available on this actual moment.
When this is just about HTML5 semantics like header, footer, nav, section, article, etc, we simply can use some simple tricks so we can still use them in our markup.
But first of all, why do we want them in our markup?

Does it give us any advantage at all? Why bother?

Its all about adding some extra semantic richness to your document. This is good for the accessibility of your document.
Screen readers know exactly what the navigation is, and what the main article is, so in theory this could replace the 'skip to content' anchors as an example.

Another advantage of using HTML5 semantics is for search engines optimization, or SEO for friends.
You can define more clearly which is which, and what is what in your documents, and this all tastes like sweet apple pie for search engines.

Enough ranting, let's look at a small trick, so you can start using those semantics without letting down those older browsers without HTML5 support and javascript turned off.

  1. <header>

  2. <div class="header">

  3. <h1>Page Title</h1>

  4. <h2>Page Subtitle</h2>

  5. </div>

  6. </header>

  7. <article>

  8. <div class="article">

  9. <header>

  10. <h1>Article Title</h1>

  11. </header>

  12. <section class="main">

  13. <div class="main">

  14. Article goes here...

  15. </div>

  16. </section>

  17. </div>

  18. </article>

And a CSS example:

  1. div.header {

  2. color: #000;

  3. }

  4. div.article h1 {

  5. color: #fff;

  6. }

You see, the point is to create a child div for each HTML5 element, and we use those div's in our CSS selectors.
Now if we create some CSS for our markup, we don't use any HTML5 element in our selectors, but we use the child divs.
This way we can get the best of both worlds. We can start using those new semantics, and we have full browser compatibility.
At least the new semantics won't be the show stopper.

Any disadvantages?

Nothing is without any cost. Disadvantage of working with child divs is that you create extra, unnecessary markup.
But I think most drupal themers can cope with that. :)

Other ideas

If you know a better/other way to achieve the same, please shoot.

Jan 03 2011
Jan 03

It has been officially announced that January 5th 2011 will be etched in our memory as the release date of Drupal 7.0. This will introduce many of improvements for everyone: developers, themers, system administrators and end users. Time to take a look at 7 improvements that Drupal 7 brings for end users.

1. New core themes

No less than three new core themes have sneaked their way into Drupal 7, each targeted at it's own audience:


The new default front end theme (replacing Garland). This beautiful looking theme with tons of regions and color module support should allow everyone to create a pleasant and modern looking site without the hassle of creating their own theme.


The first administration theme shipped with Drupal core. A product from the Drupal 7 User Experience Project. Clean and no sidebars!


A CSS only theme. Ideal to test Drupal 7's default markup, or from which to create your own subtheme.

2. Improved administration interface

By means of a survey in 2007 started by Dries Buytaert, it became clear that one of the focus points for the next version should be Usability and User Experience, and in particular that of the administration interface. The Drupal 7 User Experience Project was thus started and people such as Mark Boulton and Leisa Reichelt were hired to guide the project to achieve its goals. From that project and from the various activity in the issue queue were born a few modules to enhance the experience.

Toolbar, Shortcuts, Overlay, Contextual links, hook_admin_paths

One of the most irritating experiences for some beginner Drupal users is having to switch between the administration and front end theme. Three modules and one hook in Drupal 7 finally close that gap.

After enabling these modules you get a toolbar at the top of every page with the top level links of the Management menu (think like the Administration menu in Drupal 6). Below that toolbar you get a bunch of shortcuts where every user can collect his/her favorite and most used pages. Using the overlay you never have to leave the front end page you're on. Once you access an administration page, it opens in an overlay on top of your current page and once you close it after performing your tasks, you're back on the page where you were.

Contextual links give you quick access to configure parts on a page. When you hover over a block a popup appears allowing you to edit the block, when you hover over an article teaser, the popup contains a link to edit the article, etc.

In previous versions of Drupal, the "administration environment" was constructed of every page which URL started with /admin (except for the content editing pages). Developers can now use hook_admin_paths to mark certain paths as belonging to the administration interface. Expect a few modules in contrib that will build on this to provide a user interface for non-programmers.

Vertical tabs

Vertical tabs were already available as a contributed module in Drupal 6, but are now part of core. They make long forms shorter. You will notice this when writing articles, pages, … since the node form is now a lot shorter.

Improved navigation

The whole administration menu (called "Management" in 7, "Navigation" in 6 and before) is reorganized in a much logical structure.

More drag & drop

Drag & drop was introduced in Drupal 6, it's now available on more pages.

3. Improved installation and updates

Drupal 7 ships with a full-fledged Update manager, meaning you can now update your modules and themes without doing the whole "download, unpack, upload module and run update.php" routine. Once the update manager announces an update of a certain module, you can tell it to update the particular module using the web interface, and the routine is done for you by Drupal itself behind the scenes. The Update manager can also be used to install new modules and themes. Just provide it with the URL of a module or theme or upload the tarball and you're done.

Drupal also ships with two installation profiles: you can choose the minimal profile to install Drupal with as few modules enabled as possible, or choose the default profile that enables some modules and creates some content types for you.

The Drupal core installer is also rewritten as an API which means that you can install Drupal from the command line. Try it with drush site-install.

4. CCK in core (now Fields)

Tears of joy! Our beloved Content Construction Kit (CCK) is now part of core. It is re-baptized as Fields and it rocks.

It's a whole new beast because without extra modules you can now not only add fields to all your content types, but also to users and taxonomy terms.

What the heck… it's written so generic that you can now actually add fields on practically everything (that supports it). Start the (r)evolution.

5. Lots of contrib module functionality in core

A lot of functionality existing in Drupal 6 as contributed module, has been ported to Drupal 7. It is actually so much that more than 50 contrib modules (probably even a lot more) have become obsolete for Drupal 7.

To mention only a few: functionality appears in Drupal 7 as "Image styles", complete with preview functionality and all.

Those always forgetting to set up cron or not able to, will be happy to know that 's functionality is now available in core. As soon as you have installed Drupal, cron is being set up to run every 3 hours.

6. Better user management

One of the most frustrating things in Drupal 6 was the 'administer nodes' permission which gives users more rights then you want. In Drupal 7 this issue has been solved by splitting this permission into more permissions like 'Bypass content access control', 'Administer content types', 'Administer content', 'Access the content overview page', …

Instead of only have a machine name in Drupal 6, permissions now have a human readable name and description and may also have a warning: 'Warning: Give to trusted roles only; this permission has security implications'.

To make your site more secure, you can now keep the User 1 account secret and give people "User 1 like permissions" using the Administrator role, a role that receives all permissions by default, something that was only possible in Drupal 6 using the Admin role module.

New in Drupal 7 is also that users can cancel their own account. With that also comes support to handle the cancellation of accounts (by the administrator or the owner of the account himself). You are given a few options about how Drupal needs to treat the user's content and profile.

7. Better support for multilingual sites

Drupal 6, maintained by Gábor Hojtsy, put a lot of focus on making multilingual sites with Drupal easier and better. In Drupal 7 quite a bit of cool stuff was introduced again.

Language negotiation got improved significantly. You can now completely configure what gets precedence when Drupal decides what the active language is, based on the URL, a session variable, user preference, browser settings, ...

Something you will notice as soon as you install Drupal 7 is that we now have timezone support. This also means Drupal 7 supports daylight saving time.

The translation system in Drupal 7 now also is aware of the context a certain string is used in. So for example the string "May" may be used as the month "May" in one context and used as the verb "May" in another one. In Dutch this would translate to "mei" en "mogen".

To close off this impressive round of improvements to the language system, we can also note that Search now also can work language aware.

More improvements

This list of improvements is part of a presentation that Krimson will do at the Drupal 7 release party they are organizing together with Calibrate. The presentation will highlight 42 more improvements which gives us together with the ones above 7 x 7 reasons to kick off your next project in Drupal 7. Join us!

Jan 01 2011
Jan 01

Are you already using Eclipse as your IDE for drupal module development?
If so, meet the 'Eclipse Drupal hook templates'. A XML file to import in your editor, including all drupal hooks.

Here's how Eclipse templates work:

1. Type the name of the hook, here 'hook_perm'.

2. Now press CTRL-space, the hook name will be replaced with the complete hook template.

Interested? Download the Eclipse templates XML file at the Drupal project page.

Using some other IDE or text editor?

Eclipse is not the only IDE getting all this fun. Here are three other popular solutions having support for hook templates like Eclipse:

Netbeans provides this feature using a plugin.
Textmate provides support via the Drupal bundle.
For Panic's Coda, you can get some snippets.

Written byTom Behets

Coming from the world of Sound, his interest for Drupal drove him to drop the 'engineering' for 'development' and he is now known as Tom, Drupal Developer next to being a fresh Linux fanatic. He can also always be found on IRC. In the most sinister days of his past he whored himself out to the dark side as a mercenary of spam... watch those inboxes! Plans on becoming an astronaut.

Dec 28 2010
Dec 28

And so, after nearly 3 years of production, project lead Dries Buytaert has announced that Drupal 7 will be released on january 5th, 2011. It has been a long stretch but a new major version of our favorite framework is finally upon us.

It's the perfect occasion to party. Krimson has teamed up with the Drupalistas at Calibrate to organize a release party in Brussels at the KMKG on january 7th.

Why all the fuzz? Well, with this release, Drupal will take one giant leap on the evolutionary timeline. Drupal 7 will be more stable, scalable, flexible, userfriendly,... then its predecessor. We are looking forward to welcome the Fields API, a new admin interface, an overhaul of the database layer, lots of new, handy hooks and of course a freightload of tweaks and fixes which should squash many longlasting bugs and annoyances.

All over the globe, releaseparties dedicated to this event are being organised. Check out drupal7releaseparty.org to find a release party in your vicinity.
Drupal 7 Release party - by Krimson and Calibrate
Krimson has joined forces with Calibrate to organize a release party in Brussels. We invite you to join us on January 7th at the KMKG (Koninklijk Museum voor Kunst en Geschiedenis - Jubelpark, 10, 1000 Brussel) for drinks, socializing and presentations. Krimson will present "7 times 7 reasons why you should start using Drupal 7". This party is definitely not 'Drupal addicts only'.

Entrance is free of charge, please register for this event at weheartdrupal.be.

Written byMatthias Vandermaesen

With degrees in History and Applied Informatics he found his perfect match at the City Archives of Antwerp where he did research on digitalization and digital dissemination of audiovisual cultural heritage. Dabbling with PHP and MySQL, and blogging with Wordpress he eventually actively participated in the fast ever evolving world of web. He chose Krimson to become a fully fledged Drupal ninja. Comes from infamous Bruges to Antwerp really for espionage. Secret Service reports can be read on http://netsensei.nl (The Dutch Connection) He pretends to listen to his own music when all he does is tap wires while he works.

Dec 13 2010
Dec 13

Riding the semweb

A few weeks back, we blogged about the Semantic Web and how it will gain more importance in day-to-day life. We've seen how the lack of easy-to-use tools to leverage its power is keeping it from becoming mainstream and saw how Drupal fits in the story. And so Krimson, in an effort to bring the semweb in Drupal, takes part in a Flemish government-sponsored research project called Archipel.

Archipel is a consortium of private and public stakeholders: sociocultural entities, academic institutions and private enterprises. It's a research project that runs over two years and is sponsored by IWT (Government agency for Innovation by Science and Technology) Its main goal is to create a common platform which facilitates the exchange of data in an open and transparent fashion between large repositories that contain digitized audiovisual heritage. The project relies on concepts and technologies taken from the semantic web: Linked open data, RDF, SPARQL, OAI-PMH harvesting...

Krimson has been engaged as a technical partner. Our role is to realize a series of project sites that interact with a common open data layer. These sites are real use cases with hard functional requirements issued by other partners that act as 'clients' within the Archipel project. This approach allows us to test Drupal modules that support semantic technologies, discover gaps and give feedback to their maintainers.

As the project has almost rounded its first year and parts of the platform are slowly becoming functional, Krimson also met the core goals of its first project case.

The Toneelstof case

Our first client, VTi (Vlaams Theater Instuut / Institute for the professional performing arts in Flanders), runs a successful project, called Toneelstof, that documents the history of the performing arts in the Low Countries. Over the past years, the main deliverable of Toneelstof were sets of DVD's containing archived interviews with important players (directors, actors, producers, writers,...) and other historical documents (videoclips from plays,...) VTi plays a double role: acting as a provider, their holdings are opened up through the Archipel platform. As a consumer, the Toneelstof site reuses data stored in the shared open layer.

Our other partners, Inuits and IBBT (Interdisciplinary institute for BroadBand Technology), created an environment allowing easy ingest of objects by VTi. Objects are harvested via the OAI-PMH protocol and stored in a central triple store. The objects consist of an archival copy and dissemination copies in different web accessible formats. Metadata is mapped to Dublin Core. The triple store features a SPARQL endpoint through which data is made available to the outside world. Krimson is to build a website for the Toneelstof case that can connect with the SPARQL endpoint, launch a SPARQL query, retrieve video clips and their accompanying metadata and present them to the end user in an usable and accessible way.

The website itself isn't ready for release yet, but we've made a screencast of the current state of things:

Support for Semantic webtechnology is a fast evolving domain within the Drupal ecosystem. There are no production-ready modules available off the shelf. So our options were limited. We could have build our own custom solution but that would entail several drawbacks.

  • Developing from scratch, without community support, takes a lot of time.
  • Building our own components means less chance of reusing them in other projects...
  • ... components that might not be suitable for contribution back to the community.
  • Since there are already several modules under way, we might end up reinventing the wheel.

So, we decided to base the Toneelstof project on existing modules that offer SPARQL support. This approach would cover the first miles without having to invest extra effort. If we were to need a new feature or encounter bugs, we could dive into the code and contribute our own solutions as patches to the different module projects. We would also enjoy the benefits of community feedback as we published our patches for testing.


It became quickly apparent that SPARQL Views would become our weapon of choice. This module allows you to to compose and issue queries to remote SPARQL endpoints through the Views module. Building on top of the Views API gives development a serious boost since it does all the heavy lifting: handling of filters and arguments, rendering of an entire view, rows and fields, dynamic composition and execution of a query. The SPARQL Views module goal is to integrate the ARC2 library functionality in Views and adapt the interface allowing it to also handle SPARQL query composition.

Lin Clark, maintainer of SPARQL Views, has created several screencasts on how this module works:

Did we benefit from this approach? Yes, rather then building everything from scratch, we were able to spend time improving the SPARQL Views module. We ended up fixing several bugs and adding two features to the module: support for Views argument handling and Views pagers.

We had to pass multiple keywords to the View as an array of arguments. We added a primitive argument handler to the module which does just that. In SPARQL, you can add a variety of different functions to FILTER expressions though. At the moment, our SPARQL Views arguments only understand the regex() function. This is enough to suit our purposes but other useful functions still need to be implemented.

The module didn't support paging. We had to write a specific pager class for the SPARQL Views module. For any kind of paging to work, two queries are needed: a COUNT query to establish the total number of objects in a result set and a ranged query to retrieve the actual objects for a given page number. The SPARQL specification is actually a recommendation. This means it's still in full development and lacks certain features which are available in other query languages. A well defined COUNT modifier is not yet supported. The ARC2 library provides it's own SPARQL+ extensions which include COUNT support, but if the endpoint does not have SPARQL+ installed, a COUNT query will return an error. Instead, our pager class retrieves the entire result set. Determining the total number of objects is done in PHP. This solution works for small sets but doesn't scale well when queries return larger sets of data.

While SPARQL Views harnesses the power of the Views framework, there are several drawbacks. Views requires you to register your datasources before you can query them. It doesn't automatically read out the entire database structure. This means you have to explicitly define tables and their relationships in code using hook_views_data(). Handlers for fields, filters and arguments are statically associated with those fields. This allows Views to apply the correct handlers at runtime.

In SPARQL, variables are dynamically bound. Without a static definition of the available fields, Views does not know which handlers to instantiate. SPARQL Views tries to solve this issue by running the query from within hook_views_data() and associate a mapping based on the structure of the resultset. Views' architecture is not build to alter the data definition in the context of hook_views_data() when a query is run, though. This resulted in a series of nasty hacks on the part of SPARQL Views to register those fields and handlers nonetheless. Another tradeoff is that Views caching has to be disabled to make this work.

SPARQL Views comes with it's own generic field handler which is applied on all the attributes in a result set. Part of the flexibility of the Views framework is it's ability to instantiate specific handlers which can be assigned to fields depending on their datatype. For instance, imagecache formatters are only available for fields which are associated with the imagefield handler. SPARQL Views is not yet ready to automatically determine the type of a field and assign a specific handler. A possible solution might be tracking down the predicate of the matching triple pattern and looking at the associated schema against which the query was run. For now, the lack of typed fields restricts developers to the theming layer, overriding theme_views_view_field(), and project specific code to get the job done. Modules like Display Suite do make it easier to theme the overall view.


The best way to conclude our first year on the Archipel project is to provide an answer to a few questions.

Is it easy to query and reuse open data in our own Drupal projects?

Easy publishing RDF formatted data has made a few leaps in the past year. But querying data is still non-trivial. SPARQL is an unfinished specification. Major features like aggregated queries have yet to be defined. Most tools are still experimental. SPARQL Views is arguably the most flexible tool available although it's still under heavy development and it comes with it's quirks. A good understanding of RDF and SPARQL is still required if you want to ride the semweb.

What about performance?

The common triple store only contains a few dozen objects and our SPARQL queries are fairly simple. Since we don't retrieve large sets of data this means there is currently no notable performance hit at this point. With the problems we raised in the article in mind and an increase of the amount of data in the triple store under way, scaling up is our next challenge.

So, when will SPARQL Views be really ready?

This is the classic chicken and egg dilemma. Without testing and contributions, it will take longer for tools like SPARQL Views to evolve. Then again, as long as they are still experimental, developers tend to stay away from them. If the Toneelstof case proves one thing, it's this: starting to use these tools and returning feedback drives development.

How can I help?

If you're up to it, start by downloading and reading the instructions at the project homepage. The latest version of the module is available on GitHub.

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