Neighbears

I usually don't post a lot of pictures in my posts, but this is one is just to cute. I started at Krimson this monday and brought my cookiemonster doll with me - and my arcade machine too, so anyone near the Dampoort, call me and we'll have a game of Puzzle Bobble :)

One of the companies across the building also had his teddy bear with him and took the adorable picture underneath. Best Bears Forever.

Topics 

work, cookiemonster, bears

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.

The state of the fieldgroup module for Drupal 7

With Drupal 7 getting closer to release and field API, better known as CCK in Drupal 6, in core, the fieldgroup module was still left behind a bit. While Yves Chedemois (yched) was working on making the Field UI extendable from contrib, I started testing and working further on brand new code that was available on github that is destined to become the fieldgroup*1 module for Drupal 7. My colleague Jochen Stals (Stalski) also jumped in and after some internal discussion with Yves, we moved the code into a new project, away from CCK. The new module is available at http://drupal.org/project/field_group. Exciting for sure, but where are we exactly and where are we going?

Fieldgroups are everywhere *2

Every entity (node, user, etc.) in D7 shares the same UI for managing the form and display. This means that fieldgroups are available for your user profile, taxonomy or even your own defined entity. Refreshing also is that the order of fields is separated from the form and display. A fieldgroup can thus be displayed on top of the form and at the bottom of say your node - or not at all, it all depends what and where you want to show your data. Oh, and there's also unlimited nesting.

Formatting

Different formatting options are available: div, collapsible fieldsets and vertical tabs. With the jQuery library in core, it's now much easier to format also in different stylish ways: horizontal tabs and accordion are already supported. People wanting other formats can simply implement a hook to register the format and an output callback function.

Regions and layouts

Since we can output fieldgroups as a div, they can serve as containers to create a multi column layout if the right css is made available. Create nice forms or layouts for easy positioning of elements of a node, user etc. in any view mode (build mode in Drupal 6). People familiar with Display suite know we love such stuff and we're discussing how the two modules can work nicely together. The solution lies in the #region key available in the form and which module will make use of it. There is even a chance that #regions is not even needed at all and can be ditched completely. This could lead to a change in the name of this module to something more abstract like Group.

Obsolete modules

It's not our first goal, but with the power we now have in core, a few modules can be merged or easily replaced by the new version of fieldgroup: CCK fieldgroup tabs and Node form columns are two that come to mind, we probably forgot a few more. We invite maintainers of such modules to help along to bundle forces and share thoughts what steps we need to take. Documentation and guidance are most likely the key factor in succeeding.

Exportables

The module will have full support for exportables and features. Whether we'll write it ourselves or depend on CTools has not been decided yet. Input from both parties are greatly appreciated here. However, when we release, fieldgroups will be able to live in code.

Upgrade path

The upgrade path is the most difficult task. The module has been rewritten from scratch and has a complete new database schema. There is no clear plan at this moment, so input is more than welcome. We can get inspiration from the upgrade path that is partially available from CCK to field API - although at this point a lot of problems are still there.

Multigroups

Multigroups is a concept living in CCK3 (1 and 2), but has had no official release yet to this date. Support in this module is not planned yet for that reason. The code is also a bit hackisch and shouldn't probably live here anyway. Fieldable fields is most likely the answer and belongs in another project. Insights are welcome of course.

Update http://drupal.org/node/939836 is a nice start for discussion around multigroups (Thanks Yched).

Working together

Getting the module out will benefit everyone, so please test, create patches (+ tests), write documentation or record some screencasts. With the new options available to maintain a project, we can give more people access to commit or other responsibilities. Feel free to jump in, the community will appreciate all your hard efforts in making this module a huge success!

*1 There is still an internal debate whether we are going to write 'field group' or 'fieldgroup' as the title of the module or even something else (see Regions and layouts)
*2 persiflage of 'fields are everywhere', taken from the haiku written by Amitaibu for his Organic Groups presentation at Drupalcon Copenhagen.

Tag your website with Banksy

I haven't come far in my search for Banksy and I didn't get any more clues after seeing Exit through the gift shop this week where to find him - actually, not even trying to find him, however, if you, yes you, Banksy, ever read this, just send me a mail, will you? Even a single dot will do.

Anyway, after doing art on the street, galleries and now the movie, it's time to hit the internet. So, a tiny brainstorm and a few javascript lines later, I came up with this button on which you can click underneath or drag in your bookmarks browser to tag any website with a random Banksy piece. Actually, 1 is not from him, but if you, yes you, Banksy, ever read this, just send me more and better stuff to tag sites with, will you ? Or someone who's better than me creating non pixelized pictures to work on sites with dark backgrounds ...

Banksy tag!

You can also drag that link to your bookmarks bar or a tab and start tagging other sites.

On internet explorer ? Right click and choose "Add to favorites" (yes, it's safe).

Topics 

jquery, banksy, tag

Benchmarks for the Display Suite module

I've been promising benchmarks for the Display Suite module after every presentation I gave so far. It took me a while to get a good setup but now it's here. I've used the demo site as a start, so there are a lot of modules enabled for this test. Views, panels, fivestar, heartbeat, comment, taxonomy, location, gmap, imagecache are the most important ones since they all integrate with the ecosphere of Display Suite modules.

I added a new content type called 'benchmark' and added 14 CCK fields to it: 4 textfields, 4 textareas, 2 images, 2 filefields, 1 node reference and 1 user reference. It also has a title, body, 2 taxonomy fields, a fivestar widget and a couple of comments.

Depending on the test, the complete set of modules integrating with Display suite are enabled or disabled. These include ds, ds_ui, cd, hds, nd, nd_cck, nd_search, nd_fivestar, nd_location, nd_switch_bm, ucd, ud and vd. You gotta love small project names right ?

Desktop

The first test was ran on my Fedora Core 13 desktop - Intel Core Quad, 2 GHz, 2MB RAM with php 5.2.13 and eAccelerator - ab sending 100 requests with 5 concurrent users on a single node and page caching disabled.

Without Display Suite
PHP 4.91 MB
Requests per second:    36.18 [#/sec] (mean)
Time per request:       138.202 [ms] (mean)
Time per request:       27.640 [ms] (mean, across all concurrent requests)
Build mode blocked
PHP 5.31 MB
Requests per second:    34.68 [#/sec] (mean)
Time per request:       144.174 [ms] (mean)
Time per request:       28.835 [ms] (mean, across all concurrent requests)
With Display Suite
PHP 5.33 MB
Requests per second:    34.51 [#/sec] (mean)
Time per request:       144.876 [ms] (mean)
Time per request:       28.975 [ms] (mean, across all concurrent requests)

Server

The second test was ran on a CentOS 5.3 - 2 x Intel Core Quad, 2,6 GHz, 8MB RAM with php 5.2.11 and eAccelerator - ab sending 100 requests from my pc to the external server with 5 concurrent users on a single node and page caching disabled.

Without Display Suite
PHP 4.25 MB
Requests per second:    26.91 [#/sec] (mean)
Time per request:       185.775 [ms] (mean)
Time per request:       37.155 [ms] (mean, across all concurrent requests)
Build mode blocked
PHP 4.61 MB
Requests per second:    26.76 [#/sec] (mean)
Time per request:       187.072 [ms] (mean)
Time per request:       37.514 [ms] (mean, across all concurrent requests)
With Display Suite
PHP 4.63 MB
Requests per second:    26.65 [#/sec] (mean)
Time per request:       187.642 [ms] (mean)
Time per request:       37.828 [ms] (mean, across all concurrent requests))

I knew that enabling modules would cause the memory of PHP to grow on both my desktop and the server. The server however behaves better in terms of keeping the requests per second steady per setup, so that's the real good news. I'll probably run some more in the future to see how it behaves in other situations, but I'm glad that I've got some results to show!

You may lose a few microseconds, but win days of maintainability!

Pages

Subscribe to realize.be RSS