drupal

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!

To make sure we can use the Field UI forms, we declare our own entity called 'ds_views', which is not fieldable and only has one default bundle.

<?php
/**
* Implements hook_entity_info().
*/
function ds_extras_entity_info() {

 
// Register a views entity on behalf of Views.
 
$return = array(
   
'ds_views' => array(
     
'label' => t('Display suite Views'),
     
'bundles' => array(),
    ),
  );
  return
$return;
}
?>

So now that we have an entity, we create our own menu callback function which will ask for the field ui form. Display Suite will call all additional fields and add the layout options too.

<?php
function ds_extras_vd_field_ui() {
 
module_load_include('inc', 'field_ui', 'field_ui.admin');
 
$build = drupal_get_form('field_ui_display_overview_form', 'ds_views', 'views', 'default');
  return
$build;
}
?>

However, when calling the Field UI form, we'll get a message saying this entity does not have not any fields. To solve that problem, we can implement hook_field_extra_fields and return one field. In this case, the title will be overridden later on because we also implement hook_ds_fields() which will return our fields for views. 

<?php
/**
* Implements hook_field_extra_fields().
*/
function ds_extras_field_extra_fields() {

 
// Register a single field so fields for vd be picked
  // up nicely in the display overview form.
 
$extra['ds_views']['views'] = array(
   
'display' => array(
     
'title' => array(
       
'label' => t('Title'),
       
'description' => t('Title'),
       
'weight' => 10,
      ),
    ),
  );

  return
$extra;
}
?>

In the screenshot you see a couple template variables which you can now put into the regions of the chosen layout.

Impressive isn't ? Hacky ? Well .. maybe a little bit. There is even more code, because now the combination of a view and a display is recorded as a bundle within the entity I just created above. I've recorded a short screencast so you can see it in action. If you want to try it yourself, download the second alpha release of Display suite for D7 and have fun!

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. Looking at the size of that queue, we already have a lot of work, most of which are tasks/bugs/follow ups which didn't make into 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.

What's next ?

The biggest personal issue I have, is that I'm not certain by any means what will be in the next release. As an example, take a look at the feature list for Fedora Core 15. It gives me a clear overview what I can expect the next time I'll be updating my development machine(s). I'm able to read a full description, track changes and see the progress of every single feature. That's nice and comforting for me. I would really like to see such an overview for Drupal core too. It would allow me to choose in which areas I want to be involved in and I can rely others to work on area's I'm less familiar with. A nice list like this would finally bring an end to the phrase "when it's ready" on the question when a new Drupal core sees the light.

So what if we started developing Drupal 8 in an agile way, using Scrum or - our favorite at work nowadays - Kanban ? The latter allows us to bend the rules much more in a way that it would fit our situation, in our case, a gigantic community spread all over the world. What do we need and how could we possibly achieve this so we can throw out another kick ass release ?

Roles

In an agile process, several roles are defined each having their responsibilities. Most are known, but we'll define them for our excercise.

  1. Product owner: In some way, everybody owns the product as we all have our ideas. But Dries, at the very end, decides which new features need to be in the next major release and what's left out.
  2. Project managers: Together with Dries, the core committers who test the stories, make sure sprints are delivered on time, discuss and resolve problems towards developers, consulting both the latter as the PO.
  3. Scrum master(s): This is the hardest task. They are responsible to solve problems on the story level, report to PM and PO, guide developers and testers, solve interrelational problems. Experienced people who know how Drupal Core works already, not necessarily on on every level, should be appointed for this role.
  4. Developers: the community. And boy, are we lucky, we have a gigantic pool of resources. But this does not only include hard core coders. People who like design, user experience, information architecture etc. must be involved at all times too. We've seen a lot of good input from a lot of those types, but we need more, a lot more!
  5. Testers: We have a great test bot. But it can't beat every day point and clicking by the average user who will use the product on a daily basis. However, it's ridiculously easy to come up with use cases nobody has never thought of during the process, the clue will be to filter out the critical ones. 

Release planning

Before we all start coding on new things, let's try and find out what the product owner wants to see in the next release. Obviously the PO will have some wishes and as identified above, we already have a big backlog, but priorities are not always clear. In this planning, this should be made clear what is really necessary to be picked up first. Because, the sooner this is done, the better we can focus on the nice to haves. A closing deadline always brings bad advice!

Planning this meeting is not going to be easy for the scrum master. A workable solution is an IRC session on a time it fits for the biggest amount of people, and still, even then some will not get up at night to participate. This can be tackled that already a number of spoke persons stand up voluntarily so they can express the wishes and conceirns from the community. Important is that there can't be a big discussion on technical level, there's just need to be an agreement on a fairly abstract level. Stories are written with a rough estimation, tasks can be assigned, but this not necessary during this meeting. 

Backlog filling

Sprint planning

This meeting should define the primary goal to achieve towards the end of the sprint. It's important that stories in this sprint which do not lead to the success of the sprint are picked up later. This means that a sprint can contain critical, normal and low priority stories! A Drupal core sprint should at least be 2 months, we're still working with volunteers using their free time, and sometimes company time to make things better. At this point, issues can be assigned to a story which make sure we have a deliverable in which the PO, but in the end everyone is comfortable with. Once all is decided, we can start coding and try to make sure we keep up with what is planned. Change requests can occur - read, will happen -  but they should be put in our backlog and be picked up into the following sprint.

Moving stories to a sprint

Adding tasks to the Entity story

Adding tasks to the story

 

Tools

The screenshots above are taken from the great http://kanbantool.com/ website, which we introduced at Krimson - after a great learning process during my period at One Agency - use on a daily basis for clients, but also for our community work, whether it's maintaining or porting our Drupal modules, organising events etc. The project module already does an amazing job and I think with some really - relatively simple - changes we could make a more visualized and targeted picture of the path Drupal is taking. A board like I mentioned aboved for the Fedora Core release would be the great step. Being able to create meta-issues (stories) and reference other issues (tasks) with eachother is something I would gladly help to write patches for - in an agile fashion of course .. ;)

Will this work ?

To be honest, I think it could. But it won't be easy, but with the right spirit and good leadership, something like this could be achievable. Besides, how extremely cool would it be to tell we're the first community that would work like this - unless there are others, feel free to correct me. But in the end, just knowing what to expect in the next release would make a lot of people feel a lot more at ease.

Topics 

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 http://realize.be/taxonomy/term/201/feed and the URL for the drupal tag is http://realize.be/taxonomy/term/50/feed. Planet tags will also be posted on http://drupal.org, 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!

Topics 

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 api.drupal.org and php.net.
Question: Which bookmarks should I really have ?

Display Suite for Drupal 7: taking full render control over any entity

With CCK merged into core in what is now called Field API and the birth of entities, the possibilities of Display Suite and controlling the layout of objects have now become a much easier task than in Drupal 6. I've been working on the port since a good week now and got most things working with less code, but more goodies.

The biggest changes

  1. The module is now dependant on http://drupal.org/project/field_group, the new fieldgroup module Stalski and I (with the help of a few other colleagues) are now maintaining for Drupal 7. It defines a 'Region' format which DS uses to create any number of regions for your object. More info about field group is available in a previous blog post. DS is not dependant anymore on field group.
  2. The module now extends on the Field UI module, also shipped with Drupal Core. This UI gives you full control over the form and display for any entity in Drupal Core or defined in a custom module. This means default support for nodes, users, comments and terms without having to install any of the sub modules (Node, User & Comment displays) which existed in Drupal 6. It also means that we don't have to maintain our own interface anymore, because it's more mature now.
  3. It's now possible to create any number of regions. We ship with a couple of predefined layouts which have default css and a template file that can be (un)loaded in any occasion. HTML 5 will be a piece of cake from now on as we also ship with HTML 5 template files by default per layout. Defining or configuring the setup of custom template files from a module or the UI is easy and done in a few steps.

Previous implementations

As mentioned before, ND, UD and CD are not ported to Drupal 7 since they have moved to DS core. There is no consensus yet what we're going todo with the Node Displays contributions project as it holds some fine code for a couple of contrib modules, especially search and location. There's a big chance that code will eventually also move to this module, maybe as a separate sub module, the following days and weeks will make that more clear.

See it action

The code works, so go to http://drupal.org/project/ds and download the 7 development release. If you don't feel that adventurous yet, I've created a small screencast about the current working version, it only takes about 7 minutes of your precious time. There is a lot of polishing work todo, but I'm confident that we'll actually get a stable first release out the day Drupal 7 will be released.

Pages

Subscribe to RSS - drupal

You are here