Although the web is full of scripts to help downloading from rapidshare with a premium account, none of them seemed to work for me. First, create a cookie file: curl -k -c .rapidshare -d 'login=USERID&password=PASSWORD' 'https://ssl.rapidshare.com/cgi-bin/premiumzone.cgi'. In the browser first you click the "premium user" button, second you click "download". We download these pages because the first contains the number of the rapidshare server actually containing the file, like rs123.rapidshare.com and then the mirror like rs123gc3 for Global Crossing.

<?php

In previous Drupals we had a rough version of plugins -- you could load a cache plugin instead of cache.inc 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.

• 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.

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.

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.

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.

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).

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.

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.

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.