The drop is always movingYou know that saying about standing on the shoulders of giants? Drupal is standing on a huge pile of midgetsAll content management systems suck, Drupal just happens to suck less.Popular open source software is more secure than unpopular open source software, because insecure software becomes unpopular fast. [That doesn't happen for proprietary software.]Drupal makes sandwiches happen.There is a module for that

Drupal 7 multistep node forms are easy

Submitted by nk on Mon, 2010-03-08 01:21

The bane of multistep node forms are validation errors. But Drupal 7 has a cure. Not nice but a cure.

Slap #access = FALSE on form elements you dont want to see in the current step and then set up the Next button with #limit_validation_errors set to the elements you are about to see. The Prev button should get an empty #limit_validation_errors. Should field validation errors bother you, you can nuke those in hook_field_attach_validate.


Multiple forms together

Submitted by nk on Sun, 2010-03-07 02:45

I have written a Drupal 7 module which allows you to put together any number of forms into one <form>. For example, if you have a professor with various titles and you have created a title entity with the various fields necessary to describe that title then you can show all the title entity forms on the user edit form in a seamless manner. Co-maintainers are welcome.

Do not use github

Submitted by nk on Thu, 2010-02-04 11:24

If you use git then use gitorious or or anything that's not github. Reasons:

  1. github source code is not available. This makes me very uncomfortable. Who knows what might happen to the source code hosted there. I am not saying they will sneak in a backdoor but they could.

Drupal 8: everything is pluggable

Submitted by nk on Sat, 2010-01-23 20:17

In previous Drupals we had a rough version of plugins -- you could load a cache plugin instead of but that was all. The pluggability was on file level and it only existed for very few files. Drupal 7 introduced many more pluggable subsystems and now the pluggability happens on a class level (mostly). We can plug in sessions, cache, queue, field storage, password hashing... Crell is working on unifying these for quite some time now. And this is all good, however, for Drupal 8 I would like to see a lot more.

Some Drupal 7 porting tips

Submitted by nk on Fri, 2010-01-22 08:32
  • UPDATE/INSERT often can be updated to a single db_merge.
  • Don't forget to ->execute() your db_select/db_insert/etc
  • Themes can have many variables and you might want to do
    function theme_fivestar_preview($variables) {
      $theme_definition = fivestar_theme();
      foreach ($theme_definition['fivestar_preview']['arguments'] as $key => $default) {
        $$key = $variables[$key];

    Edit: merlinofchaos suggests simply extract($variables, EXTR_SKIP); because that's what templates do.

Just how big we are?

Submitted by nk on Fri, 2010-01-15 13:55

Up until now, Drupal tried (and tried hard) to work with every nick-and-dime shared hosting companies. We have changed course with the launch (and the success) of the GoPHP5 movement allowing us to use PHP 5.2 in Drupal 7. But that required a movement and was a huge change. I would believe that by now Drupal is large enough that it can set up some smaller requirements instead of worrying about which host will and which won't support it. One such has long been a problem -- the memory requirements -- but this as a problem affecting everyone and is filed and worked on as a critical bug.

Another growth problem: shrinking amount of core contributors

Submitted by nk on Tue, 2009-12-29 20:12

While Drupal 7 is awesome, it's quite clear we have a problem: we do not have enough core contributors. According to Greg's post there are less than 700 contributors to Drupal 7 core. Compare this to Angie's report on Drupal 5 and 6 where the number have doubled -- and now it shrinked. Shrinking amount of contributors combined with a growing code base is uh oh.

form identity theft

Submitted by nk on Sat, 2009-12-26 11:29

I have created a rather complicated form to be submitted to search/location. There are two ways to do this, grab the search location form and alter it or if you need to do lots of fancy AJAX stuff which require a vastly different form structure, just recreate it and the lie to Drupal about which form it is -- in other words, steal the identity of search_form. You only need two lines of code in a form_alter (you can't do this in form generation as form_id gets overwritten unconditionally).

  $form['form_id']['#value'] = 'search_form';
  $form['form_token']['#default_value'] = drupal_get_token('search_form');

Simpletest alter or why do you want to port your contrib now

Submitted by nk on Sat, 2009-12-19 10:19

As we are writing various MongoDB related handlers (cache, session, watchdog and field storage are all ready -- I will write a longer post about MongoDB) we found that there are little pieces missing from Drupal 7. Like we needed to extend a core session test and then disable the original. Turns out, we forgot adding a drupal_alter to simpletest to allow for this. So I filed a trivial issue (adds one line of code) and I hope it will get in.

On fundamental database operations

Submitted by nk on Sat, 2009-12-05 13:20

All databases I am aware of work based on CRUD: Create, Read, Update, Delete. Drupal always wanted to implement all of them nicely and now we have a nice Read in Drupal 7 with entity loading. Delete API has a very long and very sad history which I won't get into but we tried to introduce Delete API to make undo possible. As teached by many excellent usability books, confirm forms are wrong, they become habitual and are just a nuisance instead of protecting you from mistakes. The computer should just do what its operator says and make it possible to revert easily.

User login