modules

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 ?

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.

#D7CX sprint in Belgium

Update 06/01/2010
We have a date and location! See http://drupal.be/evenement/d7cx-sprint

With Drupal 7.0 Alpha 1 coming up soon, we as responsible module maintainers should start worrying a bit. How many of us have already a 7--1 branch or even commited code for modules to work with the latest Drupal ? I for one am pretty guilty and since I made the #D7CX pledge on all of my project pages, I should really start porting. However, this can be quite boring sometimes, sitting along at your desk (or in your couch, wherever ..), so why not organise a sprint, maybe 2 with the Belgium and Dutch community ? Everyone can join, either porting, testing, helping or just catching up with friends.

What do we need ? Not a lot I think:

  • a good internet connection, wifi and/or wired.
  • close connection to food: french fries, quick, pizza or a bio shop ;)
  • drinks: a few beers can't hurt right ?
  • other distractions like a Wii or Xbox

We have all those things available at One Agency in Drongen (near Gent). So that's a first spot were we can happily hack time away if anyone's interested. A complete weekend might be possible if there's a lot of enthousiasm and commitment. I'll post some dates soon on the drupal.be website. So who's in and has also a spot to share with us ?

And since this will be also my last post in 2009: happy new year everyone!

Addendum to the D7CX movement

I just spent the entire morning fixing notices and adding patches in the issue queue for a couple of contributed modules we're currently using in a project. On my development box, I always set error_reporting to 'E_ALL' and display_errors to 'On' in php.ini so I can see how good or bad the code is. Drupal core is pretty much free from such notices, but in the contrib world there's a lot of undefined variables and indexes out there. Fixing them sounds boring but is actually pretty fun and you learn a lot about the internals of Drupal core too, so it's really worth spending time on this.

A few months ago Moshe started the D7CX movement encouraging module developers to release a D7 version of their modules the day Drupal 7 is out. Excellent initiative and a lot of module maintainers already made that pledge. That's really wonderfull, but let's hope module maintainers always run with full error reporting and make their modules notice free, so why not change that pledge a bit:

I pledge that mymodule will have a full Drupal 7 release and will be PHP notice free on the day that Drupal 7 is released.

Of course, this still applies to D6 and D5 too, who's in on this too ?

Topics 

drupal, modules, planet

Dear edit button, welcome back!

It's a very old issue, a frustrating one in fact: the edit tab on nodes disappears sometimes due to input format permissions. I wrote a module that fixes this for D6 which works for the default body field , CCK textareas and I'll be adding support for other textareas on other pages too (think blocks & views). It's available in my sandbox for testing at http://cvs.drupal.org/viewvc.py/drupal/contributions/sandbox/swentel/edi.... There are a few todos left, marked accordingly in the code, so if you want to help out, go nuts! I'm not sure yet if I'll release this as an official project on d.o, I'll wait for some reactions from the community first, so leave a comment, contact me, ping me on irc .. we'll see after that.

Anyhow, say hi to the edit button again if you test it :)

Pages

Subscribe to RSS - modules

You are here