drupal

For the last few months I’ve (intermittently) been thinking about how to build a nice PHP SDK for working with external APIs from PHP applications, and Drupal in general.

This post is a sort of round up of my thoughts, hopefully I’ll find time to complete this project so I can post a detailed followup.

Read on for a quick snapshot on why I like Guzzle and how I plan to use it.

Random snippet of the day, find out what modules are involved in building out a given menu route definition. When you type a URI into your browser, Drupal’s menu routing system connects that to your page content by processing the path into instructions for how to build the page.

The other day around the office, I was surprised to discover not everyone realizes that you can do some crazy stuff around extending drush commands.

First step: Read the documentation. Drush is intentionally written to be a command-line foil for Drupal, and if you’ve built a module, a few minutes digging into the well-done docs will go a long way. Check out the Drush API if you are of a mind, or for a more focused burst of hook goodness, get out your terminal and type:

$> drush topic docs-api

Once you have a grasp of the fine hooks you can use to piggy-back on and around any Drush command, you can take it to the next level.

Between the issues queue, Twitter, podcasts, and ad hoc discussions, there is a lot of confusion about what the Features module is all about. As someone that has used and developed in it for a long time, I thought I’d lend my perspective. My sense is the maintainers are on the same page, but don’t hold them to this post.

Then

Features is a module to help site builders and command-line gurus easily package up the configuration associated with a specific use case (like a blog), and manage it in code.

Please, keep in mind this post was written for Drupal 6 and Views 2! D7/Views 3 sites might not take so kindly to it.

Recently I was looking at creating a new Todo Feature with a due date. I cracked open CCK’s manage fields UI and added a date field, careful to keep in mind that the default value should be no date, which just happens to translate as NULL. You see, for my Todo use case, not all Todos would have a deadline.

My next step was to create a View of all upcoming items. I wanted the next most urgent todo to float to the top of the list. Sadly, NULL counts as 0 in database land, so my carefully clicked Sort was preloading all my urgent todos with all the lowest priority tasks.

Seeing as this was a SQL problem, I googled the ‘net for viable query tweaks. I found a nice article illustrating exactly what I wanted: MySQL Sort Order with NULL. The grand secret? Sort first by whether the duedate is NULL to flip your empty values to the bottom of the result set.

Read on to see how I added this change to my View.

One of the neat features of Drush is it’s configurability. Setting the defaults for various behaviors and command options allows you to build really simplified, specialized workflows. You can create personal settings defaults by dropping a `drushrc.php` file in one of the places Drush will look, such as inside a .drush folder of your home directory.

The following post originally appeared on the GoingOn.com blog.

After more than a year of continuous investment in GoingOn’s Drupal 6 platform, the idea of upgrading to Drupal 7 is incredibly daunting. We have custom modules from form behaviors down to the access layer, we have features encapsulating hundreds of exported components, and an aggressive feature release schedule that does not set aside 6 months for a complete rewrite of the codebase just for a new version of Drupal. What to do?

We’ve been playing around with the idea of iterating our Drupal 6 platform toward Drupal 7. By pulling markup, design patterns, APIs, and architecture in Drupal 7 down into platform incrementally, we hope to shorten the final leap that will come when upgrading the entire system.

Some months ago I wanted the solution to overriding a Views Field template entirely from within a module. I spent hours trawling documentation and issues, and playing with a little trial and error. In the end, I came up with a solution:

There are two ways to change contexts. The new awesomeness is to use Features or other exportable techniques to create a new version of your modified contexts, and push the old ones out of the way.

However, when I avoid hacking [atrium] core, I prefer the old way–today that’s alter hooks.