JW Player module now supports plugins

The JW Player module, which is currently in development for Drupal 7 has just got the feature of being able to support plugins for presets. With this feature, it is possible to plug in all the add ons availabe from Longtail video.

JW Player plugins

There is also a Drupal preset plugin created for Google Analytics Pro2 JW player available in my sandbox. Custom modules can implement plugins by using the newly introduced hook_jw_player_plugin_info() in the JW Player module. The format to use this hook as described in jw_player.api.php is:

/**
 * Implements hook_jw_player_plugin_info()
 *
 * @return array Associative array of plugins keyed by actual plugin id
 */
function hook_jw_player_plugin_info($preset) {
  // Create a plugin keyed by its actual plugin id
  $plugins['foo'] = array(

    'name' => t('Foobar'),

    'description' => t('A plugin to do foobar'),

    // Note: Each option should be in a valid FAPI format, as it is directly referenced in the preset settings form,

    // except the '#title' may be omitted for the name of the option to be taken as default

    'config options' => array(

      'accountid' => array(

        '#type' => 'textfield',

        '#required' => TRUE,

        '#size' => 15,

        '#default_value' => 'bar'

      ),

      'param2' => array(

        '#type' => 'select',

        '#options' => array('TRUE' => 'TRUE', 'FALSE' => 'FALSE'),

        '#default_value' => 'TRUE',

        '#description' => t('Enables the controls on an item when playing')),

    ),

  );

  return $plugins;

}

As described above, the plugin is an associative array keyed by its actual plugin name as required by the player. The data basically consists of a friendly name and description, followed by configurable options that the site-administrator/editor can set per preset, which would look something like:

JW Player preset settings

If the preset plugin is enabled, when viewing the source code of your page that contains a JW Player video, you should be able to see the plugin added to the player code; something like:

How to use hook_query_alter() to alter Views in Drupal 7

Sometimes you need to alter a Views query by using the regular SelectQueryInterface methods without having to use the Views data structure in hook_views_query_alter(). It may get tedious at times working out all the views relationships, and arguments separately and adding a simple 'groupby' may get tricky if you do not have aggregation set in the view. It could also be that your hook_views_query_alter() runs a little too early for the $query to be modified.

Luckily, when the Views query is built in views_plugin_query_default::query a unique tag is added to each view of the form 'view_<view_name>':

// Go ahead and build the query. 

// db_select doesn't support to specify the key, so use getConnection directly.

$query = Database::getConnection($target, $key) 

  ->select($this->base_table, $this->base_table, $options) 

  ->addTag('views')

  ->addTag('views_' . $this->view->name);

Note: views_plugin_query_default::execute adds access data to the query which should be used for building access rights to the query during execution.

So, in your hook_query_alter(), you could identify the view based on its tag and modify the query like any other SelectQuery. I found this easier than using hook_views_query_alter() many times.

Example to group by a specific field: 

function hook_query_alter(QueryAlterableInterface $query){
  if ($query->hasTag('view_my_custom_view')) {
    $query->groupBy('n.type');
  }
}

Themeing EVA views using custom templates [patch]

Entity Views Attachment lets you attach a view to a Drupal 7 entity. This means when viewing a node, you could display for example, a list of other nodes by the same author. See http://www.theweek.co.uk/columnist/michael-bywater

But due to the way the views plugin was written, it was not possible to use custom templates for EVA views. If you tried to, you would end up with a lot of 'underfined variable' notices for all the variables in your custom template.

E.g.
Notice: Undefined variable: title in include() (line 31 of /../sites/all/themes/../templates/eva-display-entity-view--gallery--entity-view-1.tpl.php).

There is a hard dependency on eva.theme.inc even when overriding eva-display-entity-view.tpl.php to a custom tpl. Due to this, template_preprocess_views_view() is not run.

The patch in http://drupal.org/node/1205008#comment-5130160 fixes the above limitation by removing the dependency from hook_views_plugins().

Its all a dream they say

In my dream I conjure up characters, including myself. I am very real in the duration of my dream. I do things, I see other people. I feel emotions. Sometimes I also see myself from above doing different things, often connected to me past interactions with people. And then I wake up. All the characters and myself disappear away and I am back to my present self. It was all a dream, they say.

Where did all those characters go? The events in the dream seemed real, even though the colours were not as vibrant and vivid as the non-dream state. We have always pondered about what happens to the soul after death. Life is energy, so it has to transform from one form to another?

I believe the answer to the question of where one 'goes' after death is also similar to what happens to the characters of a dream on waking up.

Hinduism suggests the whole world is Maya (an illusion). Do illusions change form? What if we do not involve the perceptor?

Varnish simple purge

So whats a Drupal 7 developer to do if he needs to launch a highly dynamic anonymous site and needs to plan caching strategies? Use Varnish cache of course.

But if your site is as dynamic as mine, Varnish will display stale entries unless its TTL is set to something like 1 hour. For a dynamic news site then, surely you need automatic rules to purge pages from Varnish on new or updated content? For e.g. the homepage is changing constantly! The index pages will also change often.

There are currently two modules in the pipeline that should offer the ability to purge pages (cache ids) from Varnish, instead of the whole Varnish cache (oh God, no!):

1. Cache Expiration, and
2. Cache actions

While waiting for these more suited modules to have a stable, usable release on Drupal 7 production sites, I had to create a very simple module -Varnish Simple Purge - that allows site admins/editors to purge individual urls from Varnish.

We don't want to give them too many options, cos by experience we know they will use all :) Finally Varnish will more often be empty - not a good state to be in.

Hence with a Varnish TTL of 1hour and a simple purge mechanism to purge pages immediately if needed, my news site is working way faster than its non Drupal predecessor. Oh did I forget to mention that this site is a port from a bespoke CMS to Drupal?

Other cache clearing mechanisms we use are time based views cache (in-built in views). What we would really love is this port of Views Content cache.

Managing optional features in a Drupal Distro

So you need to build a comprehensive distro using features to export data into code. Fair enough. What could be one of the most common problems in trying to create a common solution for all sites?

Problems:

1. 20% of the sites would want additional fields
   
   In your distro, say content type 'article' has 10 fields and needs 2 optional fields. All sites will use the 10 'core' fields and the 2 optional fields may or may not be used.
   
   
2. Some sites want to alter field labels and change display settings on content types

Solutions:

1. Separate overridable feature for extra fields per content type
   
   Export the main content with 10 fields into one feature and the optional fields into another feature. Site builders can leave the main feature alone and modify the extra feature only (change field permissions, usage, labels etc.)
   
   Perhaps its not easy to export the content type with the extra fields left out. In that case, manually remove the field's references from the export files. Usually those will be in *.features.field.inc & *.info files.
   
   Then export the extra fields in a separate content type and manually add a dependency to the main feature.
   
   
2. template_preprocess hooks.
   
   Consider encouraging site-builders to place all field alterations in appropriate hooks such as hook_form_alter() and hook_template_preprocess_page()
   
   
3. Override field display settings
   
   This module is still in its infancy but its possible to export field display settings separately into a feature. A comprehensive guide can be found here - http://www.agileapproach.com/blog-entry/new-paradigm-overriding-drupal-features
   

Space shuttle cockpit

A few years ago, I remember posting this interactive view of the Airbus A380 cockpit.

And now I am as thrilled to get this link for the Space shuttle cockpit

Google's April fool 2011 - Google motion

Its always a pleasure to blog about the April fool's joke played by Google each year. For 2011, its the Google motion way of communication.

Wonder if anybody would really start doing the 'motion's! Good exercise anyway!