zonageek

Most of you won’t understand anything on this post. If you have developed a couple of plugins, you might understand half of it. If you are an MT developer at Six Apart then you will probably get it all, ‘cause I’m writing this for you.

The following are three things I found sorely missing from MT. There are many more, but these three have come to mind often when developing plugins. I’m making them public in the hopes that someone notices and develops them. I might do it myself and send sixapart a patch, or maybe someone else will. In any case, if you understand what I’m talking about, please read more and comment, and if you don’t, please disregard.

Plugins should be self contained.

As is stands right now in MT3, plugin developers have to spread their files outside the plugins directory, in extlib and in tmpl, for example, in order to include modules and use the templating mechanisms built into MT.

There are ways to overcome this limitation and make a plugin self contained. I know it’s possible, I did it. But it wasn’t easy. A couple of changes in MT could make it a whole lot easier.

First, add the ‘plugins’ directory to @INC so plugin modules can do a simple “use MyPlugin::Module.pm” without having to mess with @INC themselves.

Then, change the templating functions so they can look for templates in multiple directories (i.e. a “plugin_main.tmpl” inside the plugin directory that can reference MT’s default “header.tmpl”).

And finally, don’t use SCRIPT_URL as the pointer to “Main Menu”. When inside a plugin’s UI, “Main Menu” should point to MT’s main menu, not the plugin’s cgi.

That’s all (at least for now) that’s needed for self-contained plugins.

And in case you’re wondering why a self-contained plugin is a good thing, just think about the installation instructions for it: “1- Extract the folder. 2- place it inside ‘plugins’. 3- enjoy”.

Objects should provide storage for “third-party” information.

Currently, if your plugin needs to store more information than the fields provided by MT’s objects, you’re on your own.

You can always define your own objects, using MT’s great framework. But that means you might need to create new database tables because MT dosn’t do that, and that means lots of potentially confusing installation instructions, and it means the data might not be backed up and so on.

There is a simple solution for this, based on the fact that 99.9% of those plugins just need to store one or two pieces of data regarding an entry or comment.

Take MT::Object, add an extra “user_data” field, make it an associative array (hashmap, %thingy, etc), and serialize it in and out of the database. Maybe through an “userdata” function that handles the serializing, or through code in “MT::ObjectDriver”.

That simple field can be used by plugins to add (keyed to the plugin name, of course) any kind of simple information without having to deal with the complexity of new object classes.

Add more UI hooks

Plugins should be able to add more user interface elements to MT. Right now, they can only add a link to the main menu or to the end of the entry editing page.

Plugin developers need a way to add HTML to the end of most objects ‘edit’ pages, and get a callback to process posted data. This is the only way a plugin can really extend MT in an effective way.

Right now, if you wanted to really enhance MT’s entry editing, you need to modify MT. There is no way of doing it “cleanly”, unless you’re willing to restrict yourself to a link at the bottom of the page.

The problem is that providing this feature to plugin developers is not just a matter of changing a few lines of code. It involves arrays of html, non-collinding form variable names, multistep form validation callbacks, and error handling, lots of error handling.

It’s going to be hard, I know… but it’s worth it.

That’s it

Well, at least for now. There are plenty of other things to wish for, but those three are the ones that I think are most important.

Care to add your list? Any comments? Suggestions? Maybe I’m completely of track, maybe I’m missing something or doing things “the wrong way”. But hey, at least I’m doing things.