I still remember the first "Aha!" moment I had as a new Drupal developer. I had a node form that needed something or another changed on it, and I remember beating my head against template.php for hours until I finally broke down realized I may need to write a custom module to facilitate this change. At the time (which was like eight years ago), I was very much the Drupal n00b, and my experience with writing custom modules was very limited and relegated mostly to writing custom admin forms and the like. After what seemed like hours of scouring through API documentation and forum posts I saw that what I needed to do was implement something everyone was calling: hook_form_alter().

Eight years later and probably hundreds of thousands of lines of code later, I can't imagine my life as a Drupal developer without hooks. Hooks allow us to, well, "hook" into various parts of Drupal and override, change, or add to its behavior. I won't delve into exactly how hooks work, as that's another article, but suffice to say they make my life a lot simpler.

The move from D5 to D6 did not give us many more new hooks to work, but many existing hooks were improved upon. The advent of $form_state is one major improvement that comes to mind immediately. Well, in D7 hooks have gotten the love they deserve. Yes, there are a lot more hooks now, and yes, that means a larger core, but that also means more flexibility for module developers.
 

In part 1 of this series of articles, I discussed D7’s new database layer and we started looking at what to expect with examples of static and dynamic queries. Those queries are for fetching information from a database, but what’s changed from D6 to D7 when it comes to manipulating the information in our database? The answer: a lot.
 We’ll start with INSERT queries. In D6 we were relegated to two options when it came to INSERT queries. We could either write out an INSERT query the long way:

<?php
  $query = "INSERT INTO {node} (title, uid, created) VALUES ('%s', %d, %d)";
  db_query($query, 'Example', 1, $timestamp);
?>

Or, we could use the function drupal_write_record():

<?php
  $record = new stdClass();
  $record->title = 'Example';
  $record->uid = 1;
  $record->created = time();

  drupal_write_record('node', $record);
?>

This was a vast improvement over D5 certainly, but could still result in some cumbersome code. Looking back to the first article in this series I discussed how D7's database layer is now built on top of PDO. Let's see how we handle an INSERT query in D7 utilizing this new API.

With Drupal 7 right around the corner, I have recently put myself to the task of ramping up on what's new, what's changed, and what do I – as a module developer – need to know when I sit down to code my first D7 module (or upgrade one of my D6 modules *shameless plug*). I've spent the last few weeks scouring over the D7 core and API documentation, and let me be the first to tell you if haven't heard it yet (unlikely): better times are ahead. For all of us.

The amount of API changes from D6 to D7 are broad and sweeping. D7 is certainly still Drupal, meaning that it still feels and acts like Drupal. Nodes are still nodes that can have taxonomy and comments, users are still users with roles and permissions, so on and so forth. But nearly everything under the hood and in the UI, for that matter, has been improved upon and/or refactored. From a coder’s perspective, I am soon to be in developer’s heaven when D7 goes stable. From the standpoint of being a framework, D7’s API is more mature and modern. You could almost think of D6 as a kid in highschool and with D7 that kid has graduated and is now ready for the real world. The refactoring that has taken place over the last couple of years and all of the new features now available will be a boon for module and theme developers alike. This also explains just why we have had to wait so long for a stable release. It’s almost as if you took your grocery-getter car to Q from James Bond for an “upgrade”. But, I digress.