Synopses of DrupalCon Brussels

Welcoming remarks

Dries and Boris got in front of folks and talked a bit about DrupalCon.

This is the 5th DrupalCon in only two years. People came here from several countries, one person from as far away as Singapore! :)

Big news! The next DrupalCon will be on Yahoo! campus as part of Open Source CMS Summit!! Woohoo!!

With a 20 Euro donation, we also got "Hello Drupal" shirts, made by Steven Wittens, with the Druplicon looking like Hello Kitty. ;)

New system for releasing Drupal contributions

Derek Wright (dww) talked to us about the changes he has in mind for the New system for releasing Drupal contributions, and provided a handout for everyone with an overview as well as a series of questions.

Overall, the idea is to allow module developers to create "in development" versions of their modules for each release. For example, right now you can make a 4.7 version of your module, and a 5.0 version of your module, and a "HEAD" version for unstable, in-develpoment code. But you can't have a "HEAD" for your 4.7 version, so contrib authors either end up making a "modulename2" project, or adding unstable code to their 4.7 release that a lot of people depend on, which is no good.

We talked some about tag naming conventions, how to make the process easier for themers and translators, etc. Overall, the changes mean that you'll need to know a bit (more) about CVS, but if you don't choose to use this advanced tagging, things should be more or less the same for you.

Forms API 3.0

Adrian, godfather of the original Forms API, unleashed his vision for where Drupal should go with what is mis-named as "FAPI 3.0" but should really be like the "API API." ;)

It basically moves Drupal to an MVC type of pattern, with lots of bits taken from other MVC systems such as Ruby on Rails and Cake PHP, as well as CCK and import/export API.

(I'm going to attempt to restate this but it's probably wrong so wait for Adrian's notes ;))

You define a model in a structured array (pretty much how you declare a form now), which is a collection of fields. Fields are sort of short-cut methods of declaring common things like titles (which by default have a title of "Title" and are filtered as plain text), cotent fields (which need an input filter selector), ID fields (which correspond to a node/user/etc. ID), file/image fields, and so on. Each field defines "views": an edit widget (so a textfield for Titles, textarea for content fields, etc.) and a display function. All of these relations are stored as callback functions.

One of the nice things about this is you can now cache forms and things, because the structure and the callback functions to call won't change each time, although the _result_ of those functions will.

Adrian also has some sample source code that show how this stuff works together. I assume he will post this at some point. :)

This move would basically unify things like the user and node apis, and turn it into the "everything" API, and allow you to _alter pretty much anything. Cool!! :D

We talked about how long it might take to implement this, and it was generally decided it would take about 2 release cycles. The immediate goals should be to get in the 'p' notation (more on this in a second) and registering the callbacks.

The 'p' thing: Right now, you have to denote properties with #something because there needs to be a way internally to tell $form['something'] and $form['#something'] = ... Adrian has a proposal to instead use the syntax of:

where p is short-hand for "__properties__" (or "__pretty__" ;))

Lunch

chx, dww, Kjartan, Chris Johnson, and I all went to lunch to talk about CVS issues. Something I really wanted to do, particularly in response to the increased requirement to know tagging/branching in CVS now, was code a web-based interface for people to upload new versions of their modules and themes and have the system tag/branch automatically. I got talked out of it talking about the complexity that would be required on the backend side of talking to/from CVS. Another option is auto-generating the CVS command(s) that need to be copy/pasted in or something.

Something we did talk about instead though was a web-based interface for handling translations: So it will scan through core/a list of modules, and list all the strings, along with a textarea with what translation exists for that langauge, if appilcable. then people could submit translations through a web interface. This seems like a good thing to try and do, so that people with 0 "code" or developer knowledge can contribute in this way.

Advanced form API workshop

Chx gave a presentation to talk about two tricky aspects of the Forms API: the #tree and #parents properties, and hook_elements. And then, he walked through the "flow" of how forms are created.

For the most part, the items in his talk are summarized in the following handbook pages:

* http://drupal.org/node/48643 - #tree and #parents
* http://drupal.org/node/71892 - Form API flowchart

Some other pointers:

#value != #default_value != #return_value

#default_value == just the default value of a form input.
#value = _the_ value. the user cannot change this!
#return_value = only used for checkbox and radio values, and reflects what the choice should return.

Make sure you use the "value" appropriate to your needs. ;)

Something dww brought up was the idea of making a "code validator" module which goes through and checks for you doing "silly" things like:

or

Could also be adapted to check for SQL injection, XSS, and even code style issues (tabs vs. spaces, etc.) Oooo... ;)

How Lullabot built MTV UK on Drupal

Jeff Robbins, Ted Serbinski, Alec Hendry and myself (once in awhile ;)) showed off the mtv.co.uk site and talked about how we implemented various things.

Little tid-bits:
- All pages exactly the same markup, just different CSS applied.
- A lot of CSS patches for Drupal core came out of this project
- Using CCK a lot - for landing pages, for news items, for artists, etc.
- Lots of logic at the theme layer to bring in different bits, based on taxonomy/menus.
- Flash integration with dynamic avatar builder.
- Content from Drupal site powering tv channel content.

Some of the modules used:
- buddylist
- CCK
- flatforum
- image
- image_exact_sizes (user profiles)
- lovehate
- modr8
- timymce
- votingapi (various voting on videos, love/hate, etc.)
- webform (competitions)

Performance details:
- mysql query cache
- Zend accelerator
- InnoDB tables
- 32-bit Linux
- memcached

Drupal Foundation

Dries gave a discussion on the Drupal Association, a legal association to handle issues like collecting donations, event planning, and so on for Drupal.

The association has been something that's been talked about for literally years. Dries recently went to San Francisco and spoke with a number of people from existing open source projects who have an entity behind them to talk about various strategies and approaches. Dries, Dries Knapen, and Steven Wittens have been putting a lot of work in getting this hammered out with various lawyers and whatnot. This foundation doesn't exist just yet, but all the groundwork has been laid, so it's only a matter of time.

The most important thing is that development decisions stay within the community. The Drupal Association can only assist the Drupal community, it cannot actually dictate anything like "comments must be nodes," for example.

Membership will be made up of "Permanent" members, who are made up of both the board of directors and people selected by the permanent members to be community ambassadors. These are the only members who have the ability to vote on resolutions. There are also "Admitted" members, either corporate or individual members, who pay a membership fee. Corporate members have the ability to provide an "advisory" vote. The permanent members are currently Dries Buytaert, Dries Knapen, and Steven Wittens.

Membership pricing will be structured according to "type" of membership. This ranges from 50 Euro for individuals, 500 Euro for a basic corporate sponsor, up to 10,000 for "Gold" corporate sponsorship. Corporate members have an advisory role on decisions, as well as their logo on the association website. Individual members do not have these rights, although any member of any type will have their names listed and can have buttons/badges etc. to represent themselves as a supporter for Drupal.

Much more info (and probably more accurate info -- sorry, trying to type this and listen at the same time ;)) available from the association website, http://association.drupal.org/

thanks webchick.

the corporate memberships are a really good idea. it'll give drupal a steady source of income. (and maybe produce a really well-maintained paid membership module!)

is there a date for the opensource cms summit at yahoo? will it be in February 2007?

I think you can ask for a sliding scale donation at the Yahoo. I'd be happy to give more than $30 US for Drupalcon

All I can say right now is: sleep deprivation.

http://www.flickr.com/search/?q=drupal&m=tags

see you next in Barcelona`07