Drupal: Showing related content based on taxonomy

Everyone knows that the taxonomy module allows one to categorize your content using both tags and administrator defined terms and is very flexible for classifying content. You can create one free-tagging vocabulary for everything, or separate controlled vocabularies to define the various properties of your content.

By using views in conjunction with taxonomy, one can easily create a block of related content.

For example on www.OyeStyle.com, we have articles categorized by one vocabulary called as "Main" and another vocabulary called as "Subcategory". These contain a fixed set of terms. We also allow a taxonomy with free-flowing tags for that much more flexibility and further categorization.We wanted to show a block of related articles based on the taxonomy on each page and of-course views was the answer. The link here at http://drupal.org/node/65375 details out as to how to go about it for D5 and D6.

However due to the free-tagging entries, we were ending up with a long list of articles diluting the "meaning" of related content in some ways. Here is how you can pick up related content by using specific taxonomies by avoiding free tags:

After following the instructions above in the drupal link, go to your view and edit the "Taxonomy: Term ID" argument. We then need to modify the PHP code specified for the default argument handling. Modify it thus:

$node = node_load(arg(1));
if ($node && $node->type == 'article' && $node->taxonomy) {
foreach($node->taxonomy as $term) {
$vocab = taxonomy_vocabulary_load($term->vid);
  if (empty($vocab->tags))
      $terms[] = $term->tid;
}
return implode('+' , $terms);
} else { return; }

The key difference in the above code is that for each taxonomy term associated with the node, we are getting the vocabulary associated with it . We then check if this vocabulary allows free tagging and ignore it if so (the empty($vocab->tags) check does this). Do not worry about the performance implications here, the vocabulary will most probably be cached across future calls. One can possibly do other modifications to the above code. For example, lets say you only want terms from a specific vocabulary. That can be done by:

$specific_vocab_name = 'Main';

$vocab = taxonomy_vocabulary_load($term->vid);
  if (strtolower($vocab->name) == strtolower($specific_vocab_name))
      $terms[] = $term->tid;


The above code will only pick terms belonging to the 'Main' vocabulary.Basically modify the vocabulary checks appropriately to get the desired results.

I hope this was useful. Check out the working functionality on Oyestyle by browsing through the articles there! :)

CDN with Drupal and Parallel module

Am getting good exposure to Drupal land and am loving it so far. I have to be hands on for my work and that is the best way to gain knowledge and expertise - be hands on, nothing beats it!

The current speed of www.oyestyle.com is pretty good, but I wanted to be armed for the day we hit bigger numbers :), so I was testing out the possibility of using a CDN to serve out the static javascript, css and image stuff on the site.

First, I also looked at some Indian CDN offerings. Obviously if the data is being served from close to India, it will help the target audience. But both Airtel and Tata offerings seem to be out of the reach of people who are just starting out. I also checked out the Marcellus guys, but they seem to specialize only in videos. Am thinking and looking at MaxCDN guys currently.

Anyways, the article is about setting up a CDN quickly. For this, we are planning to use the Parallel module. It is not strictly a CDN module per se, but what it does is that it allows you to specify [sub]domains that you can use for your js/css/image files. The page preprocessor code then replaces all references with those domains. This is all you need to do to set it up!

If you have a pull-based CDN like MaxCDN on the other side, then you do not have to upload any files to it too. If it cannot find the file, the cdn will fetch it from my server and then serve it from then on. It will handle this transparently! Will get back with my experience soon :)

Drupal source code and [g]vim/cscope

When you start looking at modules developed for Drupal - you kinda get lost amidst all the references to different system functions - user_external_load, db_query, etc. It becomes really maddening!

Fortunately a cscope-enable gvim binary will ease out the source code browsing angst to a large extent. Amongst all the other things, here is what I have in my .vimrc

if has("cscope")

   function! CScope_Refresh()

cs kill 0

 !find $PWD -name \*.php > files && cscope -b -i files

!find $PWD -name \*.js >> files && cscope -b -i files

!find $PWD -name \*.module >> files && cscope -b -i files

!find $PWD -name \*.info >> files && cscope -b -i files

!find $PWD -name \*.install >> files && cscope -b -i files

!find $PWD -name \*.inc >> files && cscope -b -i files

cs add .

!rm -f files

endfunction

comm! -nargs=0 R call CScope_Refresh()

endif

After you have sourced your .vimrc again, you can navigate into your Drupal install directory, fire up gvim and just hit :R and you will be able to search for symbols, look for references to functions, look for files etc. using the standard cscope commands:

e.g.:

:cs find g user_menu

The above will lead us to the definition of the user_menu function in user.module. 

Hope, this post will relieve some of your source code browsing pangs :)

Why Drupal..

The first major decision that we at had to take at Yuva was about which infrastructure piece to use for the first version of our product launch. Our's is a web-based product. We want to incorporate elements that engage and inform the user-base in various interesting and socially-viral ways. We also want to provide group based interaction, public-private access control features etc. etc. I hope you get the drift! :)

Coming up with hand-crafted code to do all the above seemed a daunting and an insurmountable task given that we want to be out there ASAP. It was then that we started looking around for open-source alternatives.

Drupal and Joomla came up trumps in that research. The idea was to take something off-the-shelf, understand it better and then customize, extend it for our needs. Then come the difficult part of actually deciding between these two. Googling up can actually be a frustrating exercise. For every positive reference you will find an equally disparaging remark too. For every positive user case study you will find an equally pulling-my-hair-off-in-frustration use case too. Tough job!

In the end we have decided to go with Drupal. They seem to have a large thriving community and a lot of websites seem to be coming up on its platform. Additionally Drupal 7 (when it will be launched) seems to further improve on the capabilities provided and the user-friendliness aspects too. Finding good Drupal talent (to hire) based out of India has been an issue so far. But we are trying to build the expertise in-house, because this is a core-requirement which we think we  cannot out-source at all.

Will post back on our Drupal experiences in the coming months - stay tuned!