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

Settings

Submitted by nk on Tue, 2010-10-12 05:29

In Drupal 8, besides settings.php I would like to see a non-PHP settings file, writeable by the webserver. settings.php would contain the secrets, the database settings, site key etc but most things that are variables now would become settings, loaded from a file. This would avoid the chicken-egg problem of how to load settings that are required to get to the database? In Drupal 8 we want to have plugins (like the cache in D7 just more generic) and this would provide an excellent place to put the plugin registry.

My (current) stance on Drupal 8 and OOP

Submitted by nk on Thu, 2010-09-30 22:56

Drupal is in the business of throwing the doors wide open so setting bear traps beneath the windows is wasted effort. In other words: I am not going to oppose any OOP in Drupal 8 as long as no more protected keywords are added and the current ones are removed.

The truth about field storage in Drupal 7

Submitted by nk on Mon, 2010-09-27 04:58

Much to my surprise, someone decided to warm up the old debate about field storage, stating that Drupal 7 will be much less performant because of it. That Drupal 7 is a little slower than Drupal 6 is true, but that's not because of how we store fields (rather because the increased use of rendering) and it's not a terrible slowdown either (one can say it's a win when used wisely because of the render cache).

On Drupal 7 modules

Submitted by nk on Mon, 2010-09-20 08:54

Drupal 6 modules typically defined their own tables, had their own code to maintain them and then used nodeapi to hook into the system. Or, defined node types but still maintained their own tables. In Drupal 7 instead you should just create fields, instance them on node types you want to work with. Instead of altering a form directly you can write a widget. Display your data with a formatter. Don't worry about data storage, field API handles that for you. And then there is the EntityFieldQuery class to help with finding things.

Reacting to sexism: it's still relevant

Submitted by nk on Wed, 2010-08-25 07:53

The Drupal community is remarkably not sexist and yet... Yesterday, Dries' keynote, alas, had a sex scandal slide which probably just wanted to be a (rather tactless and tasteless) joke but it had rather sexist undertones which have managed to piss off a number of women. But, my frustration is not just from the keynote but the reaction, let me quote two tweets here: "Woman on stage at #drupalcon, Dries can have his sextape in 2010." and even more importantly, from someone who retweeted it and got called out for it "Don't take it so seriously. It was a joke, right?" Now, head over to http://rocktreesky.com/reacting-sexism and you can see that three years ago (exact to day) the documentation team leader of Drupal have written exactly, word-for-word about this. It is absolutely unacceptable behaviour and not a joke to degrade women who have made DrupalCon possible for you to sex objects. As Addi noted in her linked blogpost, sexism won't stop just because we write about it, however, I hope this accident will actually make the community even more refusing about sexism and it will be unnecessary to write about it for at least another three years and we can work together on releasing an awesome Drupal 7, 8...

MySQL UPDATE and Drupal 7

Submitted by nk on Mon, 2010-08-23 12:31

Let's say you have an UPDATE query which uses old values to calculate new ones. The best example for now is swapping two columns: UPDATE table SET f1 = f2, f2 = f1. There is one SQL engine as far as I am aware where this breaks: MySQL (it works on PostgreSQL, SQLite and MS SQL). On MySQL, f1 and f2 both will have the old value of f2 instead of swapping.

So where is Drupal 7

Submitted by nk on Sat, 2010-08-21 19:21

While Drupal 7 has been quite long in the making, it's going to be very different from every release before: we have added tests that make sure core works well. (BTW it took quite some time to write so many of them!) This allows the core developers to focus their attention on deeper problems which are much, much harder to fix. Instead of "OMG node preview is broken!" we now contemplate "you know, this new File API is great, but it won't work well with Amazon S3 because..."

OOP and PHP or why Drupal rocks and some mistakes

Submitted by nk on Tue, 2010-08-17 06:28

Everyone knows I am not too fond of OOP. And yet, I had some role in crafting DBTNG. I now admit: DBTNG in its current implementation is a mistake. Making the stream wrappers a class -- although PHP mandates that -- is a mistake.

Drupal and Java (we want to be friends with Enterprise, right?)

Submitted by nk on Mon, 2010-08-16 23:57

Drupal 7 might work with Java databases. Eventually, we might even be able to run Drupal 7 on Google App Engine.

Serving static content from a different domain in Drupal 7

Submitted by nk on Wed, 2010-08-11 19:14

We wanted to serve static content from a CDN -- but it's the same if you only want to move your static content to a different server. This is fairly well researched and done in Drupal 6, here is the Drupal 7 version. It seems that some theme stuff (like the favicon and the logo and probably unaggregated CSS/JS) is passed as Drupal paths into file_create_url while aggregated CSS and JS is served from public://. So we need to implement file_url_alter and override the getExternalUrl of the DrupalPublicWrapper class (thanks goes to Damien Tournoud for pointing out the latter):

User login