The current versions of subscriptions module have 'blog' type hardwired. However, with configurable types and Views, this is no longer favorable. Here is what you will see, probably in a block:

Note: this is a reformatted repost of the original, I have my moved my blog and that entry was not in the dump. It needed a reformat anyways...

I had a node which stored user profile data and upon blocking said user I wanted to clean it up. A little bit later I will post the code -- for now let it suffice that I needed to use $profile->{$key}[0][$k] = ''; instead of $profile[$key][0][$k] = ''; . I consider myself a not-too bad PHP coder but this syntax took me quite some time to figure out.

Just today, two patches has been committed that has tremendeous importance: one, the AHAH patch by quicksketch was realizes the JS capability Eaton and I have put into form API 3. I spent ten days at the end of April in a Chicago motel just to work with Jeff on form API 3 and with this patch committed, I feel the invested money and time was worth it. Second, another form API enabler was committed which was originally written by me but I had so little time then that dopry submitted it to the queue so I am not even mentioned in the comit message. Credit issues aside, http://drupal.org/node/121620 makes writing widgets so much more powerful and a bit easier. All in all, I am content with the form API we will have in six.

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.