For Drupal module developers, hooks get all the glory, and for good reason. Hooks make our lives much easier when it comes to figuring out how to implement a client's complex business requirement.

But the unsung heroes in Drupal's API are its rich suite of utility functions. With each iteration of Drupal, developer feedback and community effort have added to that list functions that increase our efficiency and help make Drupal a better CMS framework.

I have been a Drupal developer since 2005 and I can remember several instances where I've said to myself - elbow deep in code - "Man, I wish Drupal just had a function that did this for me." Oftentimes, developers in the field create utility modules that contain reusable helper functions that address those needs. Sometimes we're lucky and those developers contribute back and we all benefit.

I remember how giddy I was when I saw the introduction of drupal_alter() and drupal_write_record() in D6. Or how I can't imagine life without module_load_include() now. All good things indeed that make the coder in me warm and fuzzy.

In this article, I'm going to show off a few new utility functions shipping with D7 that have stoked my interest. The first function is one that I'm sure nearly every module developer has implemented in some fashion themselves at one time or another: debug().

In part 1 of this series of articles about my favorite new Drupal 7 hooks, we looked at the incredibly useful hook_page_alter(). I also stated that in this article I would write about another awesome new pair of hooks:  hook_query_alter() and hook_query_TAG_alter().

If you read my previous article: Drupal 6 vs Drupal 7 Database Primer - Part 1 then you know that in D7 we can build structured queries, also known as dynamic queries. Essentially, we're just creating a query object and by calling certain methods of that query object Drupal generates a SQL statement and executes it. Pretty straightforward, but here's an example as a quick refresher:

<?php
$query = db_select('users', 'u');

$query
  ->condition('u.uid', 0, '<>')
  ->fields('u', array('uid', 'name', 'status', 'created', 'access'))
  ->range(0, 50);

$result = $query->execute();
?>

There's an additional method we can call on this query object:

<?php
$query->addTag('mymodule');
?>

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.

After many months of work, BriteSparkz LLC is happy to announce the opening of a private beta for Drupal Jobz.Drupal Jobz is an online system for matching Drupal projects with qualified and vetted Drupal service providers.  These matches are made based on various detailed matching criteria that help to ensure that the right Drupal projects are matched with the right provider.We are currently accepting applications from companies who provide Drupal related services and would like to be included in our private beta.  Please click here and provide the information requested to help our team determine how best to include your company in the beta.  Please note that currently we are seeking providers who have 7 or more employees. Individuals are currently not being considered for this phase of the project, but will be at a later date. The number of beta slots is limited and not all applications submitted will be accepted.  ©2010 Drupal Jobz - BriteSparkz LLC | All rights reserved. Drupal is a registered trademark of Dries Buytaert 

I was tasked recently with providing a client with the ability to export Ubercart orders to a .csv file formatted accordingly for their own internal reporting processes. No biggie, right?

Ubercart comes out of the box with an order management view that can be tweaked to our heart's content and integrates right nicely with Views Bulk Operations. Now, when I hear the words "view" and ".csv" in the same sentence nowadays I immediately go to ol' faithful: Views Bonus: Export.

Today I learned an important lesson in the realm of Drupal module development, namely a lesson in what I will refer to as: coder complacency, but this lesson could just as well be called a lesson in coder humility. Having earned my daily bread as a web developer for nearly 8 years now and having been a Drupal module developer for the better part of 5 years one could say I am comfortable around code. But, in code land – just as in many other aspects of life – with comfort can also come peril. When we are comfortable and complacent we drop our guard and lower our defenses.