The long term plan is a complete reengineering of the system, addressing all of the problems that people have been having with it (all the 500 errors, the resource overuse problems, and so forth) including support for my secret project (which should hopefully keep the list of plugins a little more up-to-date by spreading out the work instead of making Kristine do all the work to keep the existing plugin list current).

This would be a significant time investment on my part to accomplish. And while I want to do it, I will be mostly stealing a few minutes here and there to work on it. In all honesty, any monetary (or otherwise) dontations to help defray the time-costs of all the work that needs to be done will be greatly appreciated.

Either way, I will be keeping everybody updated as progress is (slowly) being made.

I honestly just have not had the time (or incentive sometimes) to put fingers to keyboard to fix a number of the problems some people have had with the PM. It has been such a massive time-sink in the past that I hesitate to put some aside for it when I have got so much else that needs attention.

Some things I would like to accomplish when I can find the time:

• More public access to the source code repository as I finally do start getting some work done
• Getting (back) together a good group of testers so I can be sure things are much improved before I make the next public release
• Fixing the problems people have reported with the overuse of system resources
• Creating an mt-check.cgi like script for the PM that should hopefully catch a good deal of the problems beforehand.
• Reworking with the new features available in MT 3.0 in mind
• ???
• Profit!

With the changes the new version of MT will be introducing, there will need to be a number of changes behind the scenes of the PM, so I may as well take this opportunity to try and work out most of the problems people have run into with the current version.

As always, thoughts, comments, questions, suggestions, volunteers, and donations are more than welcome.

cd /usr/ports/www/MT-PM/ && sudo make build install clean

Or, like I like to do:

sudo portinstall MT-PM

Enjoy!

So, for all you FreeBSD + MT users, enjoy!

(Oh, and there is a MT port as well)

The main reason is that, since the Plugin Manager works with entire files, there is currently no way to upgrade a particular plugin without a completely replacing all the associated files. And because the plugin files are removed and replaced with updated versions, any configuration settings set within the files itself are reverted back to their distributed defaults.

In addition to that, configuration through the Plugin Manager will remove the need to write file parsing code if you currently store configuration information in a file outside of the plugin itself (though, if that file is distributed with the plugin itself, it will currently suffer the same fate as the plugin file, but that can be tweeked).

There is also the basic validation that the Plugin Manager can provide, along with a consistent interface for the user. And I am sure there are probably a few more benefits that have not come to light just yet.

So, to sum up, here is why Plugin Manager Plugin Configuration is a good thing:

• No loss of configuration data during upgrades
• Use of existing code to store and access configuration data
• Consistent interface for the blog administrator

I hope that has cleared things up a little. I apologize for getting a little too ahead of myself and not giving any insight into my reasoning. :)

So, to start with, here is some sample code that might appear in remote post:

my $blog_id = 1;
my $author_id = 1;

eval "use MT::Plugins::Config;";
if (!defined $@) {
    require MT::Blog;
    require MT::Author;
    MT::Plugins::Config->add_variable ( Blog_ID => {
        plugin          => 'remote post',
        var             => \$blog_id,
        desc            => "Destination blog for all remote post pings",
        allowed_values  => { map { $_->name => $_->id } MT::Blog->load },
        use_hash_values => 1,
    });
    MT::Plugins::Config->add_variable ( Author_ID => {
        plugin          => 'remote post',
        var             => \$author_id,
        desc            => 'Author as whom to post remote post pings',
        allowed_values  => { map { $_->name => $_->id } MT::Author->load },
        use_hash_values => 1,
    });
}

Basically, the idea is that this plugin can operate with or without the Plugin Manager installed. If it is not, the user just changes the values in the initial declaration. Otherwise, the Plugin Manager can handle the validation and storing of the values.

So, let me go into a little more detail about all the hash keys I plan to include:

• plugin: Plugin name
• var: Reference to the variable that should hold the configured value (if you don't understand exactly what a Perl reference is, think of it like a pointer).
• desc: Description of the variable
• allowed_values: Hash containing possible values for the variable
• use_hash_values: If set to a true value (i.e. 1), the Plugin Manager will display the hash keys to the user for choosing, but will store/assign the hash value of that key. Otherwise, it will only use the hash keys.
• regexp: While allowed_values explicitly sets the possible values, regexp gives you a little more flexibility. Just set it to a regular expression that the value of the variable must match (e.g. '\d{1,3}' for a 1-3 digit number).

In the future, I would like to expand this to include dynamic lists of values. To use remote post as an example, I would use it to define a list of remote post id's that a site administrator could use to designate different author-blog-category combinations.

Any thoughts? Concerns?

• If the file ends in .pl:
  • Evaluate it
  • Test to see if it creating any tags or filters using the regular plugin API
    • If so, place the file in the plugins/ directory
    • Otherwise, place it in the base directory
• If the file ends in .doc, .htm, .html, or .txt:
  • Place the file in the plugins/docs/Plugin-Name/ directory
• If the file ends in .pm:
  • Attempt to extract a package name (e.g. package A::B::C;)
  • Place the file based on the package name in the extlib/ directory (e.g extlib/A/B/C.pm)
• Otherwise, place it in the plugins/docs/Plugin-Name/ directory

Update version:

• PluginManager-0.1.8-update.tar.gz
• PluginManager-0.1.8-update.zip

Full version:

• PluginManager-0.1.8.tar.gz
• PluginManager-0.1.8.zip

I will not be posting the URL to the general public, as it is just my server machine sitting on my cable connection, but if you wish to keep up with the bleeding edge of Plugin Manager development, get in touch with me and I will send you the address.

Next: my plugins repository.

• New Feature: Automatically checks mt-plugins.org for updates if the last check was more than one week ago.

You can download just the updated files here:

• PluginManager-0.1.7-update.tar.gz
• PluginManager-0.1.7-update.zip

Or you can download the new full version here:

• PluginManager-0.1.7.tar.gz
• PluginManager-0.1.7.zip

Updates for Plugin Manager v0.1.5:

• Improved error handling (not perfect, but better)
  • Better reporting of problems in updating the plugins list
• New Feature: New Plugins List
  • Plugins that are new to the list since the last time you updated (initially all of them) will be identified

You can download just the updated files here:

• PluginManager-0.1.5-update.tar.gz
• PluginManager-0.1.5-update.zip

Or you can download the new full version here:

• PluginManager-0.1.5.tar.gz
• PluginManager-0.1.5.zip

Enjoy!

I cannot promise any flashy updates just yet, but I do plan on getting rid of some of the more annoying bugs that have shown up. Stay tuned.

And, if you haven't heard already, around when the DNS changes should have worked themselves out, I will be getting married. Unfortunately, some people won't be able to make it, but that just means they'll owe me a visit sometime in the future. :) After that, Jenn and I will be on our honeymoon in another part of the state. Don't go making any sinister plans though. Our four attack cats and my sister-in-law will be watching over the apartment while we're gone.

What does this mean for the Plugin Manager you ask? Well, I've done some work over the last week or so (I do love taking time off work for once), but not enough to warrant a new release just yet. I'll try to finish it up and get a new version out by around Friday or Saturday of next week.

Things to look forward to in the next release:

• Display of new plugins since the last update of the plugin list
• mt-check-like functionality to try to ease the install problems people seem to be having

And hopefully soon I'll be able to iron our my ideas for doing plugin configuration though the Plugin Manager, so I can start implementing, so other plugin authors can take advantage of what the Plugin Manager can offer them.

Fun, fun, fun. :)

The Plugin Manager requires the following Perl modules:

• XML::Simple
• Archive::Zip (for .zip files)
• Archive::Tar (for .tar.gz files)
• IO::Zlib (for .tar.gz files)
• Compress::Zlib (for .tar.gz files)
• Digest::MD5

To install, download one of the archives available on the MT Plugin Directory and unpack it. The files should be placed on your installation of Movable Type as follows:

• Manager.pm should be placed in the extlib/MT/Plugins/ directory.
• mt-pm.cgi should be placed in the base MT directory (where mt.cgi is located). Make sure it can be executed (e.g. chmod 755).
• License should be read. :)
• tmpl/*.tmpl should be placed in the tmpl/plugins/ directory. It will have to be created.
• tmpl/styles-pm.css needs to be placed in the same directory as styles.css (i.e. the static directory)
• tmpl/dot.gif needs to be placed in the images/ directory (within your static directory, along with all the other MT images)

There are a few caveats for this version:

• First of all, I cannot promise that this will work for every plugin out there. There are quite a few plugins out there, and we just could not test how well they all work with the Plugin Manager.
• Do not try to install or manage plugins that contain patched copies of core MT files. This will cause problems with your installation. Currentlly, I can only think of two plugins that fit this criteria (though it is easily possible that there are more out there): remote post and ComeBack. I will be releasing revised versions of these plugins in the near future, as well as use this situation to drive my work on adding plugin configuration functionality to the Plugin Manager.

Thanks again to Kristine for all her hard work on the MT Plugin Directory without which this project would never have been even remotely possible. And thanks to all of the beta testers for all of their valuable feedback so far.

If you find any problems/bugs with the Plugin Manager, please submit them to the MT Plugin Direcotry Bug Tracker.

Major Update: (2003-06-05 13:05)

• On my way out of the apartment to day, I realized there was a big bug left in the code released last night. I only just now got home and fixed it. Please download the Plugin Manager again. Versions released previously will not work, and may even cause errors. This bug is not the line 197 fix.