Archive for Planet Drupal

Win a Server for Life (some restrictions apply)

This across the wire from Riseup….

Win a Server for Life (some restrictions apply)
————————————————
The riseup birds have big big dreams! But, alas, we are kept super busy maintaining and improving the current services we provide. One thing we are good at is building infrastructure (and acquiring donated hardware).

So good, in fact, that we want to give some of it away in a contest we are calling the “Win a Server for Life (some restrictions apply) 2008 Extravaganza”.

We got the servers, you got the talent, baby! Here’s the deal: We provide your collective with free hardware, bandwidth, and rackspace for the life of the server. You provide an important service to a radical social movement or local community. So long as you are using the capacity of the server, we will maintain it and host it for you.

We are particularly keen on ideas to create new services that do not currently exist, services that are difficult to find, or services that meet a need for an underserved community. Examples might include VoIP for radicals, rails hosting that keeps no logs, an encrypted backup service for activists, secure DNS services, and so on.

The server in question is a quad core 2.8ghz xeon with 4gb of ram and three disk bays. Don’t bother with a formal proposal. Drop us a note at collective@riseup.net with your idea and what you are about. We will talk, figure out who we know in common, and make sweet data together.

Comments

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

« Previous entries