Do you need proof? Less than four days after posting a short and polite request to chip in for my dream laptop, googling on Toshiba R500 reveals that my humble little chipin page on Toshiba R500 is the first! The reason? Drupal.org has such an insane high page rank that none can contend and everything linked from there -- in this case the planet jumps to the top of Google.

NowPublic has a page which tries to find out the locality of the visitors based on her IP. We do not want this page to be cached (obviously). But Drupal provides no mechanism to make a page exempt from caching. By the time the page is loaded from the cache we have settings, database connection, sessions, variables and hook_init is ran. There are quite some tricks you can do even with this limited arsenal, but I found variable overrides in settings.php to be best if ($_GET['q'] == 'local') $conf['cache'] = FALSE;.

If you like my work, here is a nice way to say thanks.

I have written previously about when this guy under the nickname of RNGsoft was first stealing Drupal. He was stupid enough to ask help from the Drupal community so his rouse was quickly found. Now, Bert Boerland writes that Frans Alkemade is still stealing our work, the code and the documentation alike and he is writing nice comments about himself under various pseudonyms. Dude, that's not nice. And why I am blogging this? To make sure Bert's blog post has a higher rank, of course :D

And yes, more can be done. Let's make term_node changed nonzero only if it satisfies other where conditions in the query i am optimizing (like n.status = 1) and add an index on (tid, changed) to term_node.

So I asked David Strauss, the new Drupal resident SQL expert what he thinks of the optimization described in the earlier article. He says, not bad, but if you add n.changed to term_node and index that then the query will speed up. And it did, in a spectacular fashion. Keeping term_node.changed in sync with node.changed can be either done with an INSERT BEFORE trigger or with a nodeapi module with a module weight which is higher than of taxonomy. We picked the latter because it fits more into our code flow and easier to document.

the five latest nodes satisfying some condition. MySQL (and I believe any RDBMS) will pick the whole result set, sort it, and then limit it. On NowPublic homepage this meant tens, sometimes hundreds of thousands nodes to sort. We have a very nice box to serve database queries, but not this nice. So we implemented a cutoff -- surely anything older than some time is not front page worthy. Now it just sorts the nodes that gets submitted in a short timespan: SELECT ... WHERE changed > $cutoff_time

Next problem was cutting off nodes belonging to certain terms.

In 2004 spring, I was working as a web programmer with a friend of mine and we were just past the phase where one is sick of rewriting login for every client -- we needed a CMS. We tried everything we could find and man, they were horrible. It should be noted that Drupal in 2004 spring was hard to find.

Come May 29, 2004 Goba's talk about Drupal in a rural town in Hungary and I found Drupal and registered Drupal.org that day. Almost immediately I began to work on a client's site with Drupal -- Drupal HEAD, I think. The results were fantastic... fantastic crap, that is. I scrapped the site a few months later and has rewritten it... and that still was crap but it took some months to realize. At one point I contributed a flexinode field type (table) -- very likely this was my first contribution to the project. As this website was in two languages I got involved with i18n almost immediately. This resulted in my first core patch, let it stand here:

Alas I do not know, I am just watching what Dries does because he does it right. Despite just a year ago he was not too convinced that the Schema API is a good idea, yesterday he committed just that. We had raw SQL statements with Drupal 5.0 and below, in 5.0 we began to use the thin Drupal database layer to write SQL install statements and now we can just use arrays to achieve the same. No longer can "not sure whether this works with postgresql" hold up a patch. Yay.

On an another note, I wanted to remove the locks from Drupal -- and equally yesterday it happened because David Strauss brought in a better patch. Thanks!

You come to IRC and detail the greatest idea since sliced bread and lukewarm water. The reaction is "hey, do it!". You might think that's just "go away" in a more polite way. You are wrong. Just today EclipseGC's patch landed which changed the pager to a list. Let me quote something "feedback from other community members (chx) it was brought to my attention that this would be much better implemented through theme_item_list. Chx handed me a rewrite of the theme_pager that illustrated the basic principle, and mentioned that theme_pager_list probably needed to disappear."

This is what you will get from me if you go in and do it. I will give you feedback, I will give you code snippets to further your effort. Do not expect me to realize your idea, though.