Gotcha in the upgrade_functions plugin argument

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.