You've decided to add a bit of Node.js functionality to your Drupal site using the Drupal Nodejs Module. After some reading you realize you need to be setting up user message channels using hook_nodejs_user_channels or possibly nodejs_add_user_to_channel. This allows your application to send socket messages to groups of users. Great! But you're writing no simple application. You want to go one step further and manage these channels based not only on some property of the user object, but all users who may be currently viewing a particular Drupal served page. Suddenly the typical user channels no longer cut it. Try as you might, you'll find yourself quickly descending into channel management hell. There has got to be a better way. Thankfully content token channels are here to help.

Recently the company I work for shifted the bulk of our instant message communications over to Campfire, and established a series of rooms to discuss our various projects. This transition seemed to go fairly well, once everyone settled on their preferred client interface. I was used to using IRC and found a nice little Ruby gem that piped Campfire through my IRC client. Chatting in this environment quickly had me missing Druplicon, the friendly Drupal fueled chat bot that tirelessly serves the Drupal IRC community. I decided to look for a replacement, and after some searching I stumbled upon Hubot, a Node.js powered chat bot. It was initially built by the folks at GitHub and includes a long list of plugin scripts added by community developers. This was immediately appealing for several reasons:

As I've mentioned in a previous post sending messages from Drupal to Node is fairly easy to accomplish. However, that is only part of the equation. If we're really wanting to build a larger, more complex Node application, it won't be long before we need the client to talk to the Node server and possibly the Node server to talk to Drupal. At a glance it isn't terribly obvious how to do this with the nodejs integration module, but it turns out there are a few tools tucked in the module code that come to the rescue.

I recently found myself working on a fairly simple Drupal Commerce site. There weren't a lot of tricks to it, just a few items and an "express" checkout. So I fired up the Commerce Kickstart profile and after a few small tweaks, had it just about right. As we approached the theme, it became obvious that the commerce completion pane was going to take a lot of love. The designers had given us a unique layout for how this page should appear, complete with order specific information displayed in a kaleidoscope of containers. This was going to take some markup, and my first thought was, "it sure would be nice to template this."

I've been spending some time experimenting with NodeJS in relation to the Drupal environment. In many of these Node/Drupal interactions the NodeJS Integration module has become a key player. There is a very helpful pdf from a talk that beejeebus gave at Drupal camp New Jersey that gives few great visualizations of the underlying principles of how this module works. In essence it "takes care of the plumbing," leaving you, the developer, free to focus on how you would like to integrate. The module is easy to use, and provides a nice set of functions to quickly get rolling. To that point I would like to give a very simple example demonstrating the use of the nodejs integration module.

I should note this post deals with Views 2.x on Drupal 6.x

When Views doesn't quite spit out the query we are looking for we can turn to hook_views_query_alter(&$view, &$query) to nudge it in the right direction. This is by no means news, and there are many a blog post detailing various ways to alter the query using this function. However, recently, I ran into an odd issue when attempting to add a GROUP BY statement.

On a recent Drupal 6 site, I received a request to build a view displaying a list of users who had not submitted a specific webform. Webform of course, has some very nice reporting as well as decent views integration for submissions. However, to view users that have yet to make a submission takes some creative views argument handling.

While I'm on the topic of the Data module, I'd like share my thoughts on some of the confusion surrounding use of the Data Node module included with the package. (see issues 976292 and 898562)

It's my opinion that the bulk of the functionality in the Data Node module has been intentionally "left undone." Instead, the module is giving us the tools to allow us to implement node relationships as needed, ourselves (think API). My thinking is that this was done to allow the maximum amount of flexibility in relating other data to nodes by minimizing assumptions about what the relationship should be. I have in no way validated this with any of the module maintainers, nor is it denoted in any documentation that I am aware of. What follows is my "average" use case for this module, and some thoughts on more advanced implementations.

When working with medium to larger sized web applications, inevitably the requirement comes up for some advanced data reporting. The spectrum of requests here can obviously be pretty broad and is often beyond what you can accomplish with the default tables provided by Drupal and the installed modules. This tends to lead us to creating custom tables to track and manage the requested reports.

I thought I would throw a post up, demonstrating a "quick and easy" use case of the Stock API module, and simultaneously, give this site's GeSHi filter a quick test run.

A few days ago I encountered a site requirement asking for a simple informative stock quote block on a Drupal 6.x installation. The format required was something like:
NFLX 208.75 -1.30 Sep 13 7:30 EST
My initial thought was to enable the Stock module and simply configure and theme the built in block. The stock module will allow the management of multiple stocks on a per-user basis, and provides a block that displays this information in a table. There is no doubt that stock module is useful but in this instance it is overkill. All we are after is a simple quote from a single unchanging stock symbol displayed in a single line of text.