Make your Drupal module's variables multilingual

If you're writing (or using) a module that stores information in Drupal's variable table there might be the need to change the values of your variables depending on the language your site is currently viewed in.

To do so you'll need i18n and its submodule Variable Translation enabled. To make a variable multilingual you typically head over to admin/config/regional/i18n/variable, check the desired variable and save your settings. But, what if your module's variable doesn't show up here? That means your module didn't implement hook_variable_info, provided by the Variable Module. Luckily it really is a piece of cake implementing it. Just create a file called yourmodule.variable.inc inside the module's root directory. You could also put it in the main module file, but having a separate file is the cleaner approach. The correctly named include file will be loaded automatically.


Hide Views Results until Exposed Filters are applied with Drupal 7

I've been fighting this for quite a while and tried different approaches over time, all of which somehow worked. From using Arguments with PHP validation to implementing hook_views_query_alter there are many options. Now I found out that the latest dev version of Better Exposed Filters (released 10/2013) integrated a patch that enables the desired behaviour. In your View enable Better Exposed Filters, go to BEF Settings and check Require input before results are shown. Much less painful than any other method I used before.

Display Drupal Nodes that share the same Taxonomy Term using Views 3

Yesterday I found a great little guide that comes in handy if you want to display nodes that share the same taxonomy term as a block, for instance to show related articles directly when viewing an article: Show related nodes in a block based on taxonomy terms with Views 3 and Drupal 7. It's originally based on another article at Metachunk: Adding a related content view in Drupal 7.

I just copied the steps over here for future me:

Drupal 7: Hide a Block for a certain content type

Per default block configuration you can only decide to show a block for certain content types, the other way around requires a little bit of PHP. The following snippet hides a block on nodes of type article and blog:

  // Only show if $match is true
  $match = true;

  // Which node types to NOT show block
  $types = array('article', 'blog');

  // Match current node type with array of types
  if (arg(0) == 'node' && is_numeric(arg(1))) {
    $nid = arg(1);
    $node = node_load($nid);
    $type = $node->type;
    if(in_array($type, $types)) {$match=false;}
  return $match;

Keep your social content yours – using Drupal?

Granted, most stuff spread across various social networks doesn't seem important. But I must confess that, from time to time, I simply like scrolling through my timelines at Facebook, Twitter, Instagram and the like and I wouldn't find it too cool, if all that was gone. I don't want to talk about the actual risk of my data vanishing, rather thinking about alternatives. I remember ideas of online applications like Sweetcron, which had its primary focus on collecting the data you created across social networks and gather them in one place.

Why shouldn't we do it the other way around? Having you own self hosted platform for Tweets, Images, Blogposts, Links, Quotes – you name it. These would be translated to some basic content types, quite similar to Tumblr. And then simple publishing options checkboxes to decide, to which social stream(s) you want to share your update. Which fantastic open source software has most of the bits and pieces readily available for exactly that? Yep, that's Drupal.

Debugging Cron

I guess most Drupal site builders have had issues with cron being stuck from time to time. On a recent project I again had this issue and it seemed to be really relunctant to go away by just deleting some cron_last entries. So I dug deeper and found the Cron Debug module. Cron Debug allows you to run each cron hook individually and track the time needed to execute each hook. This helped me to quickly identify the search index hook being the cause of my troubles, as it always caused an error 500.