Archive for Drupal

Drupal 6 For Media Mover

When Media Mover was first under development, it was started on an already obsolete version of Drupal. Now with RC1 due any day now (next week, I swear) I’ve realized that I can’t wait any longer to start moving toward Drupal Six. So I’ve started the porting process and of course it is not an easy road.

I used deadwood to generate the menus system for me- mostly worked, but I’ve still had to do some cleanup, probably because my own menus weren’t that well designed. I tried having deadwood convert the full module, but kept running into errors. I think it has a greater difficulty with complex modules as would be expected. At anyrate, there is a functional patch for Drupal-5 to upgrade to six here: http://drupal.org/node/269126

Comments

CPU Throttle Media Mover

Media Mover can be pretty CPU intensive- transcoding with FFmpeg can be a substantial hit on your server resources. If you couple this with a large amount of batch processing, you are looking at high loads over a long period of time. And of course, this does not even begin to look at what is going on for your users on the site.

Drupal employs the Throttle module to handle high load situations. It looks at traffic patterns on the site to determine if a throttle condition should be employed. In considering how to limit the activity of Media Mover on a server this is an obvious consideration. One of the things that makes Media Mover (for most use cases) different than the needs of modules effected by Throttle is that it is not bound by the traffic occuring on the site- it may well be a factor, but it is not the only consideration. If a Media Mover configuration is using FFmpeg to transcode files, it is almost exclusively CPU bound. Of course there is the Apache process that kicks off cron, some degree of Drupal processing, and perhaps a MySQL hit or two, but largely FFmpeg wants to make use of the server CPU. Media Mover will cycle through sets of files that it is loading from MySQL, but again, in terms of its total impact, mostly we are looking at FFmpeg hitting the CPU.

In this case, if we want to limit Media Mover from running when a server is starting to get overloaded on its CPU we need to check the CPU load. I’ve written a fairly basic utility that does this on Linux / Unix based servers on Media Mover’s cron processing script. It allows other scripts to still access the API without being throttled, but Cron is stopped if load creeps beyond what you set it for.

You can set the threshold where Media Mover should stop, and select which average you want to use as the threshold- the one, five or 15 minute load averages. Once the load drops below the threshold, the Media Mover Cron runs will start up again.

Comments

Writing panels integration

I’m working on a project where I need to get some of my custom content into Panels. Having the Panels interface to manage things is obviously a huge boon, but I wanted to do more than create Drupal blocks- I wanted the same kind of integration that modules like Views and CCK are using.

Poking around, I didn’t find much information on how to actually write your own Panels integration, so after a few fits and starts, I just started from block.inc as an example and then have abstracted it here.
I wanted to do this in a fairly simple way- a basic definition function and then a set of functions that pass these definitions off to theme functions. I’m making an example out of my code for people to use- hopefully it is useful to see how to set this up.

First we’re going to define what the items are that will be used as panes in Panels. This is a custom function, not a Panels function.
/**
* Defines the panel content for this module.
* @return array
* array has a key which will be used as a function call and a title
*/
function mymod_panels_content_define() {
$items = array(
'mymod_item_1' =>; t('This is pane one'),
'mymod_item_2' =>; t('This is pane two'),
);
return $items;
}

Now we need to declare the theme functions that will be used. Obviously these are rather simple for demonstration purposes, but you get the idea. Note that you would name these in relationship to your declarations above. Here is the first pane:
/**
* display the content for item 1
* @param array $conf
* @return string
* html return
*/
function theme_mymod_item_1($conf) {
return "my module item 1 theme function output";
}

And the second- again, here is where you would add your custom functions.
/**
* display the content for item 2
* @param array $conf
* @return string
* html return
*/
function theme_mymod_item_2($conf) {
return "my module item 2 theme function output";
}

Now we need to tell Panels about our code. This declares what functions are responsible for handling the Panels callbacks. These are Panels functions.
/**
* Callback function to supply a list of content types.
* @return array
*/
function mymod_panels_panels_content_types() {
$items['mymod panes'] = array(
'title' =>; t('My Module panes'),
'content_types' =>; 'mymod_panels_admin_content_types',
'title callback' =>; 'mymod_panels_admin_title',
'add callback' =>; 'mymod_panels_admin_add',
'render callback' =>; 'mymod_panels_content',
);
return $items;
}

Now that Panels knows about our code, we tell it how to handle the content types. We’re going to get the items that we declared first and then assign them a few additional pieces of information to make them appear in the right places in the admin interface.
/**
* Return all block content types available.
* @return array
*/
function mymod_panels_admin_content_types() {
$types = array();
foreach (mymod_panels_content_define() as $id =>; $title) {
$info = array(
'title' =>; $title,
'category' =>; array(t('My Module panes')),
'icon' =>; drupal_get_path('module', 'mymod_panels') .'/images/mymod.gif',
'id' =>; $id,
);
$types["mymod_panels-$id"] = $info;
}
return $types;
}

When an admin adds our pane, we need to add some additional information to the pane so that we can access it during the rendering phase. In the above function, we keyed the array data with the module and function data so we can pull it out easily. Now we just need to put that data into a form:
/**
* Returns the form for a new block.
*/
function mymod_panels_admin_add($id, $parents, $conf = array()) {
list($conf['module'], $conf['delta']) = explode('-', $id, 2);
$form['module'] = array(
'#type' =>; 'value',

'#value' =>; $conf['module'],
);
$form['delta'] = array(
'#type' =>; 'value',
'#value' =>; $conf['delta'],
);
return $form;
}

Now that we’ve added this data into the form, it is passed through to the render phase. In this example, to render the pane, we are doing something simple- just pass the call to a coresponding theme function- one of the ones we declared above.
/**
* call the content to generate for the pane in question
* calls a theme(module_name_pane_name, $conf);
* @param array $conf
* @return object
*/
function mymod_panels_content($conf) {
$function = $conf['module'] .'_'. $conf['delta'];
$block = new stdClass();
$block->;content = theme("$function", $conf);
return $block;
}

Finally, we just need a function that declares the title of the pane to Panels:
/**
* Returns the administrative title for a type.
* @param array $conf
*/
function mymod_panels_admin_title($conf) {
$panels = mymod_panels_content_define();
return $panels[$conf['delta']];
}

Now you’ve got a fast way to integrate your custom content into Panels. There might be easier/faster ways to do this, but I haven’t found an examples to build from. You can download the example file here as well: mymod_panels.php

Comments

Media Mover Hearts Asset

Asset is the obvious choice if you need your users to be able to easily upload content and place it within WYWISYG editor. Media Mover is probably on the other side of the spectrum- tones of options, lots of arcane settings that will not make sense if you are not familiar with the ins and outs of rich media- further if you just want to get your transcoded media on the page.

The problem is that Media Mover is more of an API than it is an interface. In fact, you’d be hard pressed to really call it an interface if you’re an end user. A while back, I released the Auto Run module for Media Mover which runs Media Mover configurations when a node is created or updated. This really set the groundwork for starting to move toward running Media Mover configurations on specific user interactions- the ones that I think a majority of people are looking for. This approach- the transcode on create/update content- while workable, still does not give the end user control of how page layout works. For some, this is a fine middle ground approach, for others, unworkable. From my perspective, Asset provides a solid way for users to add content to their nodes. Of course WYSISYG editors are problematic, but they are not going anywhere, and hopefully, their HTML will just get better. Asset goes along way toward improving the integration between WYSIWYG editors and Drupal. Media Mover can remain a work horse for rich media, but it can also play nice when it comes to offering up its services.

From what I’ve heard from other Drupal admins and people who use the web in general, they do not want to be bothered by file formats, complex preferences, or sorting out what formats are playable and what you need for the non-playable ones. Asset, Media Mover, and FLVMediaPlayer combined offer a step forward in addressing this- users can upload “video” and get “video” on the web, without a tremendous amount of knowledge of what is actually going on. This gives the admin the opportunity to fine tune what options are available, while users get to have the fun of having a full transcoding system at their finger tips. Hence a union between Asset and Media Mover seems a perfect thing.

I did a little screen cast to show how this works. It shows the process of enabling the modules, making sure that there are profiles in the FLVMediaPlayer, setting up Asset, and the process of actually uploading and inserting with Asset. If you are not familiar with these modules, should still make some sense, though it will probably be more meaningful if you are familiar with Asset.


Comments

Auto Run Module

I’ve just added the new Auto Run module to Media Mover’s 1.0alpha3 release. This module is a straight forward attempt to bridge the gap between people who need the complex functionality that Media Mover offers and people who need their data to be converted on demand. This module will run specified Media Mover configurations on node inserts and updates- meaning that when a user submits content or updates content, the specific Media Mover configurations will be run. In addition, this functionality leverages some earlier updates that let Media Mover run only on the specific node in question. This helps keep processing overhead down.

This screen shot shows the listing of the Media Mover configurations that are available to run. Note that the administrator should choose configurations that are harvesting from nodes- otherwise it is just wasted cycles.

Comments

Import / Export for FLV Media Player

Using a similar system that I built for Media Mover, I implemented an import / export system in the FLV Media Player module which allows an administrator to move configurations from one site to another. This is great if you’re working on your development site and want to port the new configuration to your live site.

Once the 1.0 release is stabilized for both, I’ll write some functions that allow modules to define FLV Media Player profiles and Media Mover configurations in custom modules so that these can be kept under version control, making it easier to deploy changes via version control.

Comments

SEADUG Media Mover Talk


Thanks to heyrocker for the photo.

I just realized that my talk on Media Mover at the Seattle Drupal Users’ Group from this past June was posted on Blip. I guess I’m a bit behind the times! This is similar to the talk that I did in NYC with less command line and more talking. Interestingly, some of the items that are “future plans” have actually been completed already and are in the alpha releases of Media Mover 1.

The Seattle group is really impressive- super well organized, really well attended weekend with great talks and great people. Both Robin and Gregory really knocked this one out of the park!

Comments

« Previous entries