theoleschool - 6.x

Using hook_views_alter to Add a GROUP BY Statement

rho — Mon, 12 Mar 2012 15:09:21 +0000

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.

The issue can be observed when attempting to use the add_groupby function to a field in the query. As an example, say we have a node view with a few fields (node id, node title, and user id). This will give a simple query:

SELECT node.nid AS nid, 

       node.title AS node_title, 

       users.uid AS users_uid 
FROM node node  
INNER JOIN users users ON node.uid = users.uid

Now, say we want to do something silly and get this query to group by user id. A node view does not allow for this, so we turn to hook_views_query_alter.

function my_module_views_query_alter(&$view, &$query) {

  switch($view->name) {

    case 'my_view_name':

      //add the group by  on the user id field 

      $query->add_groupby('users_uid');

      break;

  }
}

We expect to see a nice GROUP BY users_uid tacked on to the end of our query, but instead there is a disturbing GROUP BY nid, node_title, users_uid. What gives? Merlinofchaos clarifies for us:

"When using GROUP BY items that appear in the SELECT must either use aggregate functions OR appear in the GROUP BY. This is enforced by postgres, therefore Views must enforce this."

It is good that Views is looking out for the rules of postgres; it's what helps make it the powerful and flexible tool it is. In this application though, I am not worried about postgres and simply want to alter a single Views query on an sql database. I know that I can pass an 'aggregate' flag to the fields in the query object to denote that they use an aggregate function, even if they do not. Worth a try...

function dsic_judging_views_query_alter(&$view, &$query) {

  switch($view->name) {

    case 'dsic_judge_incomplete':

      //loop through the fields and add the aggregate indicator

      foreach($query->fields as $key => $field) {

        $query->fields[$key]['aggregate'] = TRUE;

      }

      $query->add_groupby('users_uid');

      break;

  }
}

Turns out this works! Jumping back to our view we see the query we are after:

SELECT node.nid AS nid, 

       node.title AS node_title, 

       users.uid AS users_uid 
FROM node node  
INNER JOIN users users ON node.uid = users.uid
GROUP BY users_uid

If it looks like a hack, and quacks like a hack, then it's probably a... well ya know. However, I don't have big qualms with implementing this. Views behavior is in place to accommodate a database that, in this instance, is not being used. Further, I am already using a hook function to modify a view beyond what that view is capable of spitting out on its own. Lastly, I am able to accomplish this without modifying Views core. All of that adds up to a valid use case and helps me to sleep at night.

Viewing Users Who Have Not Submitted a Webform

rho — Sun, 04 Mar 2012 18:25:05 +0000

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.

I began by building a basic user view. I then set the style and fields to my liking, and filtered on the specific role I was looking for. So now we have views pulling a list of users that we wish to check against. To find out who has not submitted the webform, we first have to take a look at who has.

webform_get_submissions($filters = array(), $header = NULL, $pager_count = 0);

Webform has the above function in the webform.submission.inc file that does just this. You can pass a node id to $filters and the function will return a nice array of submission objects, detailing who has submitted the form. We can then add an argument of type "User: UID" to our view, select "Provide default argument" below "Action to take if argument is not present," and select "PHP Code" under "Default argument type." Here we can provide a code snippet to return a list of User ids of users that have submitted the form.

module_load_include('inc', 'webform', 'includes/webform.submissions');
$submission_array = webform_get_submissions(/*node id of webform we are checking for*/);
$uids = array();
foreach($submission_array as $submission) {

  $uids[] = $submission->uid;
}
return implode(',', $uids);

This will gives us a comma separated string of user ids. The default "Validator options" are fine but be sure to check "Allow multiple terms per argument" and "Exclude the argument." After updating, your view now filters down to users that have not submitted the webform! To double check that this is happening, you can look at the query below the preview. Near the end of the query in the WHERE clause, you should see something like users.uid NOT IN (110, 13028, 210, 107, 35329, 35330, 35331). The list of numbers are the user ids that are being filtered. If no one has submitted the form, then this of course will be empty.

Now I admit, this is kinda gross. I shudder any time I include php in configuration. It is, however, a very straight forward way to get the results requested while staying in views, therefore leaving the output in the hands of a site builder/administrator. There may be some clever ways to achieve the same thing using something like Webform Report, or even a different views configuration, but nothing jumped out at me. However, if you have solved this in a different way I would love to hear about it.

Using the Data Module's "Relate to Node" Functionality

rho — Sun, 04 Mar 2012 03:44:18 +0000

While I'm on the topic of the Data module, I'd like to 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 enabled, this functionality is apparent in Drupal's admin UI at admin/build/data/edit/%table_name/node by clicking on the edit link next to a table at admin/build/data/overview then clicking the "Relate to Nodes" tab. This page presents a form asking you which content type you would like the table related to, and the column name of the id key in the table you are referencing. Simple right? Well sorta... When you submit this form and happily skip over to views to reference the node table, it quickly becomes apparent that nothing has happened. Checking the data_table_node table in the database will reveal it to be empty. So what's up here? Is this just an unfinished piece?

After taking a look in the data_node.module things start to make a bit more sense. At first glance we see some tantalizing functions, especially:

/**

 * Add a relationship between a data table and a node.

 */
function data_node_add($table, $id, $nid) {

  $save = array(

    'data_table_name' => $table->get('name'),

    'id' => $id,

    'nid' => $nid,

  );

  return drupal_write_record('data_table_node', $save);
}
/**

 * Remove a relationship between a data table and a node.

 */
function data_node_remove($table, $id, $nid) {

  db_query("DELETE FROM {data_table_node} WHERE data_table_name = '%s' AND id = %d AND nid = %d", $table->get('name'), $id, $nid);
}

Typically I'll stop right here. I really only use the Data module for custom reporting, and when doing so I handle the CRUD functions for the new data type myself. My data type's row reference to nodes are nearly always a 1 to 1 mapping. To further simplify things for myself, the $id I use in my custom data type is often the node id of it's intended reference. This makes my calls to these functions look something like:

  //insert my_table with a nid key

  ...

  //inform Data Node of the reference

  $my_table_object = data_get_table('my_table');

  data_node_add($my_table_object, $nid, $nid);

This will populate the data_table_node table so that when we use the relationship in out data type view it will return results. Of course deletion will be handled similarly.

This is admittedly a somewhat basal interaction with this module, though it is often enough to satisfy my needs. However Data Node allows for much more complexity and has a certain level of user interaction built in just below the surface.

It's not until we start thinking about the data structures involved that the scope of the allowed complexity becomes apparent. It is easy to assume that referencing a data type to a node is always going to be 1 to 1 (much like the typical use of CCK's Node Reference.) However, this may not always be the case. It is not required that the data table's id be the nid of the node it is referencing. It only has to be unique within the table. Because of this, a large field of possibilities emerge. You may have data type rows referencing many nodes each (1 to many), many data type rows referencing a single node (many to 1), or, of course, any number of data type rows referencing any number of nodes (many to many). The data_table_node table along with the provided CRUD functions, like the ones mentioned above, will allow for this. I think that this flexibility is a big reason that the module has been left so open.

Lastly, a closer look at the Data Node module will reveal some rather fancy display functions for the underlying relationship CRUD.

/**

 * Render an add link for a given item..

 */
function data_node_render_add_link($table, $id, $nid) {

  drupal_add_css(drupal_get_path('module', 'data_node') . '/data_node.css');

  drupal_add_js(drupal_get_path('module', 'data_node') . '/data_node.js');

  $title = _data_node_get_title($nid);

  $table_name = $table->get('name');

  $class = "data_node_link-{$table_name}-{$id}-{$nid}";

  return l(t('Add to !title', array('!title' => $title)), data_node_add_path($table, $id, $nid), array('attributes' => array('class' => "data-node-add $class"), 'query' => drupal_get_destination()));
}

/**

 * Render a remove link for a given item.

 */
function data_node_render_remove_link($table, $id, $nid) {

  drupal_add_css(drupal_get_path('module', 'data_node') . '/data_node.css');

  drupal_add_js(drupal_get_path('module', 'data_node') . '/data_node.js');

  $title = _data_node_get_title($nid);

  $table_name = $table->get('name');

  $class = "data_node_link-{$table_name}-{$id}-{$nid}";

  return l(t('Remove from !title', array('!title' => $title)), data_node_remove_path($table, $id, $nid), array('attributes' => array('class' => "data-node-remove $class"), 'query' => drupal_get_destination()));
}

These are the two pertinent functions. They both return a link that will hit a page callback to do just what you would expect. Add or remove a node relationship. This allows you "expose" the functionality to the user. The link could be placed on a view or node page to allow users to add or remove the relation to a specific data type themselves, "on the fly". This, in combination with the flexibility of the relationship itself, lends to a huge variety of possible use cases with relatively few function calls.

So wrapping this up. Data Node module is best thought of as an API. It doesn't do so much right out of the box, but with minimal implementation it becomes a fairly powerful tool.

Adopting a Table with Schema using Data Module

rho — Sat, 03 Mar 2012 20:19:36 +0000

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. Along with writing all of the necessary CRUD functions to make sure our new table is managing data appropriately, we also have to provide some sort of display or an export. Views can handle this latter requirement quite nicely. So it is here that we can turn to modules like Data or the now depricated Table Wizard to bring our new table under views "control." This gives us the added bonus of taking the display configuration out of the hands of the developer and placing it into the site builder/administrator's domain.

In a recent project just such a reporting request came up. The report was fairly complex and was to be visible to a larger subset of users. I wound up managing this report with a custom table and I turned to Data module to allow views to handle the output. After installing my custom module which created the custom table, I navigated to admin/build/data/adopt. Expecting to see my table in the list of "adoptable" tables, I was a bit confused when it was nowhere to be found. After a bit of digging I realized that tables declared using Schema API were considered "owned" by the module and not included in the list of adoptable tables. This makes some sense as you don't want just any table adopted by Data. Just imagine when an admin who's not quite sure what he or she is doing, decides to adopt and then drop the node table. I'd rather not...

So this leaves us with the question, "How do I get Data module to adopt my table?" From what I can tell, the creators of the data module expect us to use the Data API to handle table creation and CRUD. Personally I don't like the idea of this. I already understand and like working with Drupal's core Schema API, and don't want to adopt another layer of abstraction. I only want to utilize Data module to throw my table up to views. So after looking through how adoption is handled in the module, I found that really there is nothing preventing Data from adopting these schema declared tables. They are simply being made unavailable to the form at admin/build/data/adopt. This lead me to attempt to adopt my table right after it is generated in my module's .install file. This wound up working quite nicely and is implemented as follows:

function my_module_install() {

  //install schema as normal

  drupal_install_schema('my_table');

  //make sure we have the data module

  include_once(drupal_get_path('module', 'data') .'/data.module');

  data_include('DataTable');

  //instanciate the table we just created with the DataTable class

  $my_table_object = DataTable::instance('my_table');

  //tell Data module to adopt the table

  $my_table_object->adopt();

  DataTable::clearCaches();
}

After installing the module you should be able to see your custom table at admin/build/data. Data module is now obviously a dependency so be sure that it is installed and enabled before installing your custom module.

I realize that I could write my own views handlers for the custom table data I am providing, but I have found that to be a fairly time consuming (and often esoteric) task. When all we are after is a single, somewhat unique report, I feel that integration with the Data module and it's corresponding integration with views is simple, quick, and more than adequate.

Quick Stock Quote on Page Refresh

rho — Fri, 16 Sep 2011 04:28:56 +0000

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.

So let's take a short step back to the stock API module. There is really one "go to" function when grabbing a quote from the stock api and that is stockapi_load($symbol). This function is defined like so:

function stockapi_load($symbol) {

  if (!empty($symbol)) {

    $stock = db_fetch_array(db_query("SELECT * FROM {stockapi} WHERE symbol = '%s'", $symbol));

    if (!$stock) {

      $stock = stockapi_fetch($symbol);

      if ($stock) {

        if ($stock[8] != 'N/A') {

          // Date is 'N/A' means an invalid stock symbol

          stockapi_save($stock);

          // Load again so it can show for the first time

          $stock = stockapi_load($symbol);

        }

      }

    }

  }

  return $stock;
}

As you can see the stock API module is wanting to store stock information in the database to be updated on cron runs. It does this as a type of database caching. This way if a site is pulling information on many stocks, potentially every page load, compounded by many users the API can retrieve the information with a simple query to the local database. Not only is this method much faster than hitting the third party service (yahoo) every time, it is able to serve saved information (especially handy if that service happens to be down or a connection cannot be established). This feature along with returning a nice keyed array of stock information is reason enough to love this function. However, I think we could go a bit simpler still. We only need information on one stock site wide, and in this instance that information should be as current as possible. Furthermore, I would like to avoid setting up a cron job to run every half hour just to keep stock information current. Rather, we look further into the Stock API and make a more basal call to stockapi_fetch($symbol);. This function is a direct call to the 3rd party service, in this case yahoo:

/**

 * Fetch the stock info for a given ticker symbol from Yahoo!

 */
function stockapi_fetch($symbol) {

  if (empty($symbol)) {

    return FALSE;

  }

  $fields = 'snl1c1ohgvd1t1';

  /*

    "s"  => "Symbol",

    "n"  => "Name",

    "l1" => "Last",

    "c1" => "Change",

    "o"  => "Opening",

    "h"  => "High",

    "g"  => "Low",

    "v"  => "Volume",

    "d1" => "Date",

    "t1" => "Time"

   */

  $host = 'http://download.finance.yahoo.com';

  $url = $host .'/d/quotes.csv?s='. urlencode($symbol) .'&f='.$fields.'&e=.csv';

  $result = drupal_http_request($url);

  ...

This ensures fresh data, without a cron run to update the database. This function is not quite as nice as the stockapi_load() function in that the array it returns is not keyed. The commented section above (from the module) comes to the rescue. It is in the same sequence as the array returned so it can be used as a reference. So to return something like our requirement example above:
NFLX 208.75 -1.30 Sep 13 7:30 EST
We would write something like:

$output = '';
$my_stock = stockapi_fetch('NFLX');
if($my_stock) {

  $output .= '<span class="my-stock-quote">'.$my_stock[0].' '.$my_stock[2].' '.$my_stock[3].' '.$my_stock[8].' '.$my_stock[9].' EST</span>';
}
return $output;

I wound up throwing a variant of the snippet above into a block created in my module, allowing me to then jump to panels and throw the output wherever I wanted.

Now I know... the example is somewhat contrived. There is no "secret" here. Everything outlined in this post would quickly be revealed by only a few minutes of looking through the Stock API module. I wanted to demonstrate that by making a simple call to the Stock API I was able to save significant time in themeing, as well as gain flexibility in function. The alternative would be wrangling the output of the Stock module's block, and making concessions for it's functional behavior. It is easy to fall into the thinking that Drupal site building is just finding a module that is a closest fit and wrestling with what it gives us. Indeed sometimes that may be the case (Organic Groups comes to mind), but to follow that line of thinking blindly is most certainly a mistake.