Configuring fields with Display Suite for Drupal 7

The 7.x-1.1 release of Display Suite comes with a couple of new exciting features:

  • Fivestar
  • More hooks and better views extendibility
  • Ability to hide the page title on full node view
  • Custom field templates via the UI

The last feature is better known as the cure for divitis feature for the field system. Or you can also call it semantic fields. The possibilities to theme entities through the Field UI have now become endless. I'll explain those changes with code and screenshots, which should convince you how powerfull and easy Display Suite can be for your website. And best of all, this is all exportable!

Fun with entities and Field UI: Views displays

Drupal 7 introduced entities. It's such a great concept, I'm able to easily port Views displays - part of Display suite - to Drupal 7. It is now part of the main package, bundled in a sub module called Display suite Extras, which also includes the 'region to block' and 'switch view mode on a per node basis' features. More goodies, less code, even more power. But back to Views, entities and overriding templates.

For those who don't know exactly what I'm talking about, a quick summary. In the Drupal 6 version of Views displays, you're able to select a single display of a view and rearrange the template variables so you don't have to override the views-view.tpl.php template file. It uses the drag and drop screen that Display suite comes with, but for D7 we decided to use the manage display screens that Field UI provides. This is great because it supports all entities, so any entity that is fieldable use the same forms in which we simply inject our extra regions. However, Views is not an entity, but in comes hook_entity_info to the rescue!

Drupal 8: an agile proposal

Drupal 7 is out. Even before the release, the community already started thinking what should happen for Drupal 8, we're just too excited to keep on working! Keeping track of which bugs, tasks and feature requests should be developed is gathered from a lot of sources and eventually - not always - created as an issue in the Drupal Core issue queue, and by looking at the size, we already have a lot of work, which are mostly still tasks/bugs/follow ups which didn't make it to Drupal 7.

New features will obviously come up: proposals and discussions are found on blogs, groups.d.o and Community initiatives. Brainstorm sessions happen at Drupalcons, IRC, local gatherings of Drupal enthousiasts or even surveys. Tracking all this activity and the current work is really hard, probably nearly impossible for every single person on this planet. Also, issues marked as critical give a false sense to me sometimes since the spectrum of things to fix is simply to wide and not focused on making sure a single piece of code is 100% A-OK. You can bookmark several URL's which lists issues based on tags (performance, theme, favorite-of-dries ..), components (node module, etc), priorities (major, critical) and so on. Simply too much to handle for one person.


drupal, planet, agile, kanban

Drupal 7 upgrade

I just upgraded my site to Drupal 7. The upgrade went pretty smooth, apart from the migration of my image content which I had to reupload. There is also a change for my drupal rss feed, which changed to another URL due to the upgrade and I'm now using a planet tag too. The old drupal tag is aliased though, so you can keep that if you like. The URL for the planet tag is and the URL for the drupal tag is Planet tags will also be posted on, so update to your needs.

It was also time for a theme change. I'm using the Sky theme and the Sweaver module to make changes to the css. Not all css is perfect yet, but that will change over the coming days. If you find any other errors, don't hesitate to contact me. In the meantime, have fun reading!


personal, sweaver, drupal

Drupal Core, a much forgotten API

Let's start with a little Jeoporday quiz!

Answer: There's a module for that, just look it up on d.o.
Question: How can I get this functionality on my website ?

More and more posts on the web are showing up with 'The top x modules you should always install', someone else even created a website for the answer. It's hard to keep up with the new releases everyday, it's sometimes even harder to find out the exact use case why a new module even gets released - although I respect the author because he's contributing, don't get me wrong on that one.

The selection criteria

There are many reasons to pick a module:

  • Deadlines: the functionality is there and the project has to be delivered on time.
  • Workflow: development teams try to work as uniform as possible on every project.
  • Lazyness: why bother writing a functionality yourself (even it you only need one function from a giant module).
  • Strong API: it helps the developer in custom modules or in deployment strategies.
  • PM has found it on the web. I'm dead serious on this one. I've had cases where I had to start on a site where I got the modules picked for me, without even consulting me.

There are other reasons obviously, but what strikes me is that from experience (I'm guilty too) and from a lot of discussions with all kinds of people (developers, project managers, etc), the gap between what the developer needs and the client actually wants has become bigger and bigger. I'm not sure why this is exactly happening, but it can have serious consequences when going live with a project.

The kitten paradox

The Drupal world has this paradigm that you shouldn't hack Drupal core or God kills a kitten. Even worse, Dries too nowadays. This somehow extends to Contrib too, since well, everytime you need to update, you'll have to make sure you have your patches ready. But what about this: every time you're using more than a 100 modules, mankind has killed a lot of kittens by having to install additional load balancers, reverse proxies, web and database servers for keeping the site up if it's a really busy one, especially with authenticated users. Adding hardware because the site is not performing well is - in a lot of cases - not the right answer.

Back to basics

Every project is unique and building a big project should really be evaluated before and - even more important - during the development process, with great care on how the site behaves in a real life situation, investigating the amount of queries, PHP memory, generation time and so on. That's not something you can do at the end. It's simply too late at that point and a lot of kittens have died already. There are great profiling tools in Devel and Xdebug should be your friend all the time. Be sure to use them all the time.

So, depending on the needs, it might be more interesting to write a simple custom module and write PHP yourself again, using either PHP or API functions available in Drupal core. Every developer should've least opened up the includes folder and scanned every file in it. I'm still amazed now and then, even after all those years. Even with Drupal 7 almost out, a lot of people seem scared because Contrib is not entirely ready yet. That's a pity, because there is some amazing stuff under the hood and you'd be pretty surprised how much you can pull off with only Drupal core, PHP and - especially - a lot of developing fun.

Answer: That should be and
Question: Which bookmarks should I really have ?


Subscribe to RSS