Grayside.Org's Syndication Island

Infinite Null: Sorting NULL to Last

Grayside — Thu, 25 Aug 2011 04:01:43 +0000

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.

The fastest way for me to apply this tweak to my feature was to hack the Views query. hook_views_query_alter() is usually a horrible decision. Once you’ve put it into code, tweaking your View a lot around your alteration can quickly result in a broken query. Meanwhile:

/**
 * Implementation of hook_views_query_alter().
 */
function example_views_query_alter(&$view, &$query) {
  if ($view->name == 'example_listing') {
    array_unshift($query->orderby, 'ISNULL(node_data_field_duedate_field_duedate_value) ASC');
  }
}

(For a longer use case on this Views bandaid, see Correcting views queries using views_query_alter)

I arrived here by turning on the Devel module, and dropping a dpm($query) into that function first thing. This gave me the array structure of my View, including the various SQL entries for the ORDER BY arguments. A quick and dirty array_unshift() forces the NULL check for my date field (the alias I also found in the $query object, there are more elegant methods) onto the top of the ordering hierarchy.

Bingo! NULL-dated nodes are sorted to last.

Terms:

Configure Drush in Your Git Repository

Grayside — Sat, 20 Aug 2011 06:53:18 +0000

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.

It turns out this little capability has provided some very simple wins for developers at GoingOn. We pass around our projects and sites as a subdirectory of a Git repository that contains various things, such as documentation, deployment tools, and drush commands. Unfortunately, this slightly irregular practice disconnects Drush from the Drupal site and excludes those drush commands from the standard directories drush scans.

We fix this by making Drush aware of the Git Repo. There is a command-line script you can use to check if you are anywhere in a Git repository. By configuring Drush to check for a Git Repo on every drush bootstrapping, we give Drush a chance to pick up a bonus, repository-specific Drush config file.

Add this snippet to your drushrc.php file:

$output = array();
exec('git rev-parse --show-toplevel 2> /dev/null', $output);
 
if (!empty($output)) {
  $repo = $output[0];
 
  $options['config'] = $repo . '/drush/drushrc.php';
  $options['include'] = $repo . '/drush/commands';
  $options['alias-path'] = $repo . '/drush/aliases';
}

This script checks the current directory for participation in a git repository. If there is one, it looks at the root of the git repository for a ‘.drushrc.php’ file to provide repo-specific instructions to Drush. We use this to configure paths to external resources that can vary by code version, as well as setting the Drupal site root for the Drupal site sihpped with that particular repository.

The last line also seeks out a `scripts/` directory in the repository root, which it will scan recursively for any files ending in `.drush.inc`. This allows us to ship versioned drush commands with each repo instead of documenting a complex individual installation process.

There are many other things you can do with a little poking about in the options for a drushrc file, to learn more start with the drushrc.php example.

Update 7/16/2012: Updated code example to the same provided in Drush docs. You can now leverage this trick outside the root directory of your code repository. Also removed not applicable git context resulting in invalid configuration paths.

Terms:

drupal

drush

git

D7 Upgrade Process: Backports to Close the Gap

Grayside — Wed, 17 Aug 2011 05:40:01 +0000

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.

Driving Current Drupal Version Closer to Expected Drupal Version

^{Usability metaphors in site architecture and development practices sometimes works.}

The extra work involved might well take more aggregate time to develop, but that time will be amortized across small, manageable pieces that can be more intelligently inserted into the development schedule.

Here are the backport opportunities we’ve identified:

Design Patterns

Vertical Tabs, Contextual Links, Toolbar, Elements, Contact

Many of the design patterns in Drupal 7 are available through a combination of backport modules and creative theming. The Toolbar module doesn’t have a backport, but peeking into the repository for the Admin Menu I spy something that makes it look like D7’s Toolbar.

By pulling these patterns from D7, we gain two benefits:

We can build out the rest of our user interface around D7 design assumptions, instead of D6 assumptions. This will save effort in a theme redesign and upgrade.

We can trickle D7 designs in front of our users, allowing them to adjust to a few changes ahead of time instead of waking up one morning to find a completely rearranged website.

Our use of Vertical Tabs liberally around node forms is not cutting edge, but has allowed us to package complex forms with a Drupal 7 pattern, instead of resorting to harder-to-maintain multi-step forms.

System Plumbing*

Drupal Queue, Admin Role, Password, File, Mail System, Simpletest

The flow of code that goes on under the hood has a few interface points where it is relatively easy to grab a D6 backport and make your modules look just a little more like Drupal 7 code.

Judging by an IRC chat I just overheard the files[] mechanism might be dropped for something simpler in one of the next few point releases.

I hadn’t realized until writing this that URL Alter was cooked into core. The ability to ignore the special rules around around custom_url_rewrite_inbound() and go straight for hook_url_inbound_alter() is great. It also makes our custom code using it D7 ready.

* For purposes of this post, plumbing refers to the flow of code and data between its storage and the rendering process. Pretty broad category.

Database & Performance

Pressflow, DBTNG, Cache Backport

You can get a lot closer to Drupal 7 performance behaviors simply by using Pressflow, which has held backports from and experiments for Drupal 7 for years.

Most members of the Drupal community are already well aware that if performance is important for your project, grabbing Pressflow is an easy and non-threatening win. By using it for D6, you will be coding against session handling that is closer to D7’s, as well as being able to make use of other performance enhancing systems, such as serving images via Varnish as an ongoing improvement across your upgrade process.

Contrib Backports

This is a category of another sort. Usually when you think about Contrib modules for D7, you are looking for the upgraded version of the modules you are already using. However, what if there is a D7 module you want to use, or at least, could use? The D6 version of that module has just become a backport to facilitate your upgrade path.

This is a good solution to deal with unmaintained modules that have since been eclipsed by more energetic projects, as well as custom code you don’t really want to see again. We’re pretty excited to start playing with the Boxes module for this reason.

I’m going to skip listing competing modules in which one has an upgrade path and not the other. The Similar Module Review group might have information that will help you find competing modules that may just be a cleaner path forward.

Thanks to Lullabot’s Friday Roundup (June 24th) for pointing out backports of Password, Contact, and File. Thanks to David Reid for creating and maintaining what seems like most of these modules.

So, did this work? We are still putting together the details of this plan. A followup post in a few months will report on how it goes. If you have thoughts about this approach to the upgrade, additional worthwhile backports, or alternate ideas on how to make the time for an upgrade, please post a comment!

Terms: