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

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.

On global warming

Submitted by nk on Mon, 2010-01-11 06:01

Just this morning I saw some tweets about how Global Warming is a "A marketable but mostly inaccurate name for something very very important." I fully agree. I would communicate the problem like this: The climate changes. Which is not a surprise because the climate always changes. Alas, it seems the direction the climate moves have dire consequences on humanity -- some places (affecting hundreds of millions at least) will have severe droughts and other places, like huge cities on ocean coasts might get flooded.

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.

Core changes announcement tweet

Submitted by nk on Fri, 2009-11-27 22:42

This is more a dream than anything else but wouldnt it be great if the bigger changes were tweeted like "themers: check this issue, we have overhauled hook_theme". Ideally some field experts would be able to look at the change (and only the change they need to know of because this way they do not need to follow the sometimes overwhelming core development) and raise red flags if it won't work for them. Yeah, I am dreaming.

Mini Drupal cycles

Submitted by nk on Fri, 2009-11-27 20:38

Continuing my previous post here are some ideas on how could Drupal development process happen in the future. Let's say on January 1 the UX team begins to work on a design. As reusable UI patterns are part of the framework, I am not specifying whether they work on the framework or the product, they work on better user experience. Their goal is to come up with wireframes, getting feedback and getting some simple mock/skeleton implementation.

Drupal 8 maintainers

Submitted by nk on Wed, 2009-11-25 22:44

As read in Dries' blog post about Drupal 8 there will be a framework and an application maintainer for Drupal 8. I would like to be the framework maintainer but obviously the decision is Dries'. My actual coding contributions have decreased significantly recently anyways and this would be a fantastic way to continue contributing to Drupal. I will write more on this blog about our goals for Drupal 8.

Again on subsystem maintainers

Submitted by nk on Sat, 2009-10-31 03:11

Two important points were brought up with my previous idea. One, communication and direction and so forth. Any patch needing that is branch maintainer territory. The subsystem maintainers are taking care of the small patches so the branch maintainers only need to deal with the bigger patches. Then comes the "but if it's a small patch then it takes no time to commit". This is simply not true -- everything takes some time -- if it takes only one minutes (I doubt they can be done so quick) then thirty of them takes away the time from a bigger one. Edit: We just had a discussion on IRC where went through a bunch of commits checking whether they are on subsystem or branch level and we found that most patches that operate on a subsystem level are really small so it might be that instead we want to name a 'code janitor' or 'yard sweeper' who can save the branch maintainers from "death by ten thousand cuts" and sweep in the minute fixes which drain the branch maintainer's time. This would just add one or at most two people making the communication overhead really small.

User login