Programmatically setting plugin defaults

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.