David Raynes Technical

Gotcha in the upgrade_functions plugin argument

2007-05-01T03:45:20Z

Plugins these days can, and often do, store their own data in their own custom object classes. The MT::Plugin class makes it very easy to set all that up for each plugin, along with versioning the overall data storage scheme for the plugin and allowing for routines to be run upon upgrading.

Here is an example cribbed from the documentation:

schema_version => 1.1,
object_classes => [ 'MyPlugin::Foo', 'MyPlugin::Bar' ],
upgrade_functions => {
    'my_plugin_fix_field_a' => {
        version_limit => 1.1,   # runs for schema_version < 1.1
        code => \&plugin_field_a_fixer
    }
}

Now, while I will readily admit this was very much a faulty assumption on my part, I thought that the keys of that upgrade_functions hash only needed to be unique within the plugin itself.

I was wrong. Very wrong.

The keys of that hash need to be unique within the entire MT installation. That means they cannot be the same as any of the core upgrade functions or any upgrade functions that other plugins might define. It look me about half an hour to track that one down.

Looking back on it now, it makes sense. Template tags, junk filters, text filters, and so forth all need to be unique within the system as well, so it being the same for upgrade functions really is not that surprising when you think about it.

So, I am publicly introducing the first of my plugin development best practices: Always prepend the name of the plugin to any key in the upgrade_functions hash argument.

Yes, this is pretty much what plugin authors do already with template tags (e.g. MTPluginNameTag), but it can't hurt to have this spelled out explicitly for upgrade_functions as well.

Getting Lighttpd and RequestTracker working together

2006-09-30T21:41:52Z

I had been fighting for a while to get my lighttpd server to serve up Request Tracker via FastCGI, but I was always having minor configuration issues with it. I finally dug up a handy recipe for a Mason (which is what Request Tracker uses) FastCGI script for use with lighttpd. After incorporating the changes necessary to deal with lighttpd's quirks, I managed to get things working as well as I would like. The following is the diff generated from the stock mason_handler.fcgi script that comes with Request Tracker:

--- mason_handler.fcgi.orig     2006-09-30 16:45:18.000000000 -0400
+++ mason_handler.fcgi  2006-09-01 18:05:16.000000000 -0400
@@ -65,6 +65,16 @@
     $ENV{'ENV'}    = '' if defined $ENV{'ENV'};
     $ENV{'IFS'}    = '' if defined $ENV{'IFS'};

+    my $uri = $ENV{REQUEST_URI};
+    if ($uri =~ /\?/) {
+      $uri =~ /^(.*?)\?(.*)/;
+      $ENV{PATH_INFO} = $1;
+      $ENV{QUERY_STRING} = $2;
+    } else {
+      $ENV{PATH_INFO} = $uri;
+      $ENV{QUERY_STRING} = "";
+    }
+
     Module::Refresh->refresh if $RT::DevelMode;
     RT::ConnectToDatabase();

And the portion of my lighttpd configuration file handling Request Tracker:

  server.document-root = "/usr/local/share/html"
  fastcgi.map-extensions        = ( ".css" => ".html", ".js" => ".html", "/" => ".html" )
  index-file.names              = ( "index.html" )
  url.access-deny               = ( ".mhtml" )
  fastcgi.server                = ( ".html" =>
                                        ((
                                                "socket"        => "/tmp/rt-fcgi.socket",
                                                "bin-path"      => "/usr/local/bin/mason_handler.fcgi",
                                                "check-local"   => "disable",
                                                "min-procs"     => 2,
                                                "max-procs"     => 2
                                        ))
                                )

Automated plugin testing

2006-08-20T04:29:12Z

One of programming mantras I try to follow is "Bugs are only found once." When a bug is discovered, an automated test is written to demonstrate it. When the test passes, the bug is fixed, and with the test around, subsequent versions of the software will be checked to see if it reappers. I have been more lax than I like with testing my plugins, but I have started to make things right.

]]> A bug in MultiBlog was recently brought to my attention: the file containing a tag that is not used very often did not even compile. It was just a little typo, but it was in software that I had shipped. I really should not have let it out of my subversion repository in that condition.

So, I wrote up a quickie test file and I run it pretty often now. It has already proved itself useful in development.

use Test::More tests => 8;

require_ok ( 'multiblog.pl' );
require_ok ( 'MultiBlog::Tags::Categories' );
require_ok ( 'MultiBlog::Tags::Comments' );
require_ok ( 'MultiBlog::Tags::Entries' );
require_ok ( 'MultiBlog::Tags::Include' );
require_ok ( 'MultiBlog::Tags::LocalBlog' );
require_ok ( 'MultiBlog::Tags::MultiBlog' );
require_ok ( 'MultiBlog::Tags::Pings' );

Using Test::Harness's prove utility (prove -l -I/home/rayners/mt/MT-3.31/lib t/00-require.t), I can make sure that all of the files involved in my plugin compile correctly.

The next step is to start building up some MT testing infrastructure using SQLite and begin testing the actual plugin functionality.

Programmatically setting plugin defaults

2006-05-14T04:01:27Z

When developing a plugin for Movable Type 3.2, you can list out all of the configuration variables you plan on tracking on system-wide or per-blog basis, along with explicit, hard coded default values for those variables. As I was working on Workflow last night, I discovered a way to programmatically set different default values for individual blogs.

]]> When writing a plugin for Movable Type 3.2, the unofficial standard (as far as I have seen at least) is to build a subclass of MT::Plugin. Then, in a BEGIN block, create a new instance of this plugin class and pass the constructor all of the plugin information, including configuration variables and their defaults.

Here is a shorted example from the 3.2 update of Workflow that I am working on currently:

sub BEGIN {
    $plugin = MT::Plugins::Workflow->new({
        name => 'Workflow',
        version => $VERSION,
        ...
        settings => new MT::PluginSettings([
            [ 'can_publish', { Default => undef, Scope => 'blog' } ],
        ]),
    });
    MT->add_plugin($plugin);
}

I am currently working on the updated configuration system for Workflow and I was struggling with how and where to set the default publishing settings for each individual blog. I ended up having the defaults generated and saved if there was no pre-existing configuration when the user navigates to the plugin configuration page in the Movable Type administration interface. That was a less than ideal solution, if you ask me. First of all, simply viewing the configuration should never alter it. And beyond that, anybody who is familiar with the plugin configuration page in Movable Type could tell you that simply visiting the plugin configuration page does not mean that the configuration for any given plugin will be altered or even viewed. So a user could browse to the plugin configuration page, view and/or alter the configuration for a completely different plugin (e.g. SpamLookup) and end up with a different setup for Workflow. That is absolutely the wrong behavior.

Not willing to settle on that, I did some digging into the MT::Plugin class and after searching for the string "default" in the file, I found the answer to my problem: the apply_default_settings subroutine. This is called by the get_config_obj subroutine, which is called whenever a plugin object accesses its configuration information (unless, of course, the MT::PluginData object is loaded directly). So, by overriding the apply_default_settings subroutine in the new plugin class, programmatic defaults can be generated.

For example, having the following subroutine in my plugin class for Workflow allows me to set the default publishing permissions on a per-blog basis (_default_perms is a method in the plugin class for Workflow that generates the default permissions for a given blog):

sub apply_default_settings {
    my $plugin = shift;
    $plugin->SUPER::apply_default_settings (@_);

    my ($data, $scope_id) = @_;

    if ($scope_id =~ /blog:(\d+)/) {
        my $blog_id = $1;
        if (!defined $data->{ can_publish }) {
            $data->{ can_publish } = $plugin->_default_perms($blog_id);
        }
    }
}

So, by defining my own apply_default_settings subroutine, I can have a plugin generate defaults in any way that I need.

Building Plugin Distributions with Ant

2006-03-28T03:27:52Z

I use Ant to build the plugin archives that can be downloaded from my site. Why Ant? Well, while I can manage to get make to compile a couple files, I have more experience with Ant, mostly because that is what we use at work right now.

]]> I keep the build.xml file in a directory named plugins/ off of my home directory on my development machine (a FreeBSD box for those following along at home). It will export the tagged release for the given plugin into a plugins/plugin-envelope-name/ directory, replace all instances of @VERSION@ in the plugin with the version number, move any files in plugins/plugin-envelope-name/php/ to php/plugins/, builds the .tar.gz and .zip files for distribution, and scp's them to my server for download, And to do all that, once I tag a release for a particular plugin, all I have to do is the following:

ant -Dversion=version.number plugin-name

And just for reference, here is a sampling of the MultiBlog repository to show what this script expects:

trunk/
- multiblog.pl
- lib/
- php/
- tmpl/
tags/
- 1.1.1/
- 1.99.2b/

It may not be perfect, and it is far from complete, but it certainly works well enough for me right now. In the not too distant future, I plan on adding the actual release tagging procedure and automatic updating of the plugin pages with the new version number. At some point, I would like to investigate other build tools, but like I said earlier, this works well enough for me for the time being.

Here is the build.xml file: