David Raynes

I just wanted to take a second to let everybody know the current status of the Plugin Manager. Basically, it is on hold. I know there are a number of problems that people have encountered with it, and I have plans for addressing them, but I really just do not have the time to work on it right now.

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.

With the semester end quickly approaching, and the pending release of the new version of MT, it would seem like the perfect time to get some actual work done on the PM.

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.

As I have mentioned before, the Plugin Manager made it into the FreeBSD ports system. The update to the port that I submitted has been incorporated, and (as I did request it) I have been assigned to maintain the port (view the commit message if you're curious). So, for all you FreeBSD MT users:

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

Or, like I like to do:

sudo portinstall MT-PM

Enjoy!

It would appear that I have achieved a new level in geekhood. I discovered this week that my little pet project, the Plugin Manager has been added to the FreeBSD ports system. It is an older version, but I have already tried to notify the port maintainers. Hopefully it will be updated soon.

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

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

I just want to give all the plugin developers out there a quick overview of why using the Plugin Manager to perform configuration is a good thing.

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. :)

To all the plugin developers out there, I would like to get some feedback on what I am currently planning on implementing for the Plugin Manager with regards to plugin configuration options.

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?

I am sure I will be opening myself up to a significant bandwidth hit, but I have decided to throw together a support forum for the Plugin Manager on my site. I have seen enough support requests in the bug tracker, and in the MT Support Forums to think that a support forum specifically for the Plugin Manager is needed.

I received a request a couple weeks ago to explain specifically how the Plugin Manager works. So, here is the list of rules that it currently follows when installing a plugin:

• 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

Version 0.1.8 is ready for public consumption. This version fixes the problem people have been having with Manual Registration.

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

It is done. I have setup a subversion repository for the Plugin Manager.

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.

Changes for version 0.1.7:

• 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

I finally made some changes for the Plugin Manager that I have been meaning to put together for quite some time now.

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!

With school winding down for the semester shortly. I may actually find some time to put in some much needed updates to the Plugin Manager.

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.

First of all, starting in a few hours, my host is going to be movnig this site to a different server. For approximately 48 hours, you could be getting one of two versions of this site (either the old server or the new server), depending on how quickly the DNS change propogates. So, any changes to the site (e.g. comments, trackbacks, etc) may misteriously disappear during that time. I'd suggest holding off on doing any of those until Saturday afternoon or so. (Note to self: look into possibility of creating a "Movable Type Go Offline" type thing, like some forums software have).

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. :)

It's here. What you all have been waiting for: MT Plugin Manager.

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.

The first public release of a beta version of the Plugin Manager is only a couple days away. I've been spending my nights working out some minor bugs that have cropped up, so they should be gone by Friday. I can't promise it will be a perfect piece of software right off the bat, but I'd bet that nine times out of ten it will work wonderfully.

Certainly this won't be the only release either. I'm sure bugs will be discovered once the public gets their hands on the Plugin Manager, so I'll have to do a little squashing. And beyond that, Kristine and I have some big plans for the future of the Plugin Manager including (but not limited to):

• plugin configuration
• patch management (see Stepan's thoughts)

So, keep an eye out for it. The Movable Type Plugin Manager will be moving out of the vaporware stage this week.

Here's another little preview of things to come.

Kristine sent me the new templates tonight, and I couldn't help but race to get them integrated into the Plugin Manager.

And on a related side note, after speaking with Stepan earlier, the scope of the Plugin Manager may be expanding in the future to incorporate other forms of MT extensions. Probably also means a name-change for the Plugin Manager.

Since the first public beta of the Plugin Manager should be released within a week or so, I thought I would take a moment to explain how it works.

• Kristine's site, the MT Plugin Directory, maintains an XML listing of all the plugins it lists.
• The Plugin Manager downloads that XML file and stores it locally.
• The file is parsed, and the Plugin Manager presents a list of all the plugins avaialble.
• Clicking on a particular plugin will bring up a page containing more information about it, as well as links to documentation, bug listings, etc.
• If the plugin is chose for installation, the Plugin Manager will verify that the local install meets the requirements of the plugin (MT version and Perl modules).
• If the requirements are met, a list of avaialble plugin download formats (.tar.gz, .zip, .pl, etc) is presented to the user
• The selected plugin archive is downloaded by the Plugin Manager.
• If the archive passed the MD5 test (to be certain that the archive has not been tampered with), the archive is unpacked (if necessary) and stored in memory.
• The files from the archive are then placed into appropriate places in the plugins/ and extlib/ directories based on extension (.pl, .pm, and so forth).
• The files installed are registered with the Plugin Manager (in MT::PluginData) and associated with the plugin, so if the plugin is later selected for uninstallation they can be removed.
• And that is it. All in all, rather simple I think.

There are a few extras that I would like to implement, but they are by no means showstoppers. So, with any luck, the general MT community will get their first chance to play with it within a week. No more vaporware for me. :)

I finally did it. The core functions of the Plugin Manager have now been implemented. It can now:

• Download a list of available plugins and versions from the MT Plugin Directory
• Determine if you can install/use a particular plugin
• Install a plugin (including downloading, unpacking, and placing files appropriately)
• Determine if there is a new version of an installed plugin available
• Upgrade a currently installed plugin to a newer version
• Uninstall a currently installed plugin

Now things start getting interesting. :)

I just thought I would post a screenshot of the working version of the Plugin Manager. Hope you like it. :)

(The templates are Kristine's work)

I released the first couple testing versions of the Plugin Manager to the testers tonight. Most of the basic functionality is there, all the needs to be done is finalizing the install/upgrade/uninstall routines and pretty-ing the whole thing up a little. :)

In fact, I am so confident in the progress that has been made so far, that I will even set a release date: Friday, July 4th. The first public release of the Plugin Manager will be no later than July 4th of this year.

Hope you guys can wait that long. :)

For those who don't already know (basically everybody but Kristine), I've started working on the Plugin Manager again. Now that work and school have eased up a little bit, I've found the time to start cranking away. I've already finished coding some of the major requirements.

With any luck, I should have some "working" version ready for beta testing by the end of the month. Is there anybody out there willing to help me out with that phase? Volunteers, please step forward. :)

Update (2003-05-20 23:07): For those interested in beta testing, I have setup a mailing list. You can sign up here.

Here are my thoughts on a possible format so far:

• Archive file (.tar.gz, .zip, .other_archiver) containing
  • Plugin file (plugin.pl)
  • Plugin Info/Doc file (plugin.xml)
  • (Optional) Pre-Install script (pre-install.pl)
  • (Optional) Post-Install script (post-install.pl)
  • Any extra files (plugin.pm, etc.)
• Single Perl Plugin file (plugin.pl) containing:
  • Plugin Code
  • Plugin Info/Docs (in POD format)

We can support one, the other, or even both. At the moment, I don't know how easy or hard it is to pull out the POD docs from a Perl script, but I don't imagine it could be too difficult.

Any thoughts, questions, concerns?

For those of you who have not heard already, I started a forum for the Plugin Manager that I'm working on currently.

Please feel free to post any ideas, questions, thoughts or concerns. I want as much input for this project as I can get my hands on. :)

There may be a little bit of confusion about what I was planning for the Central Plugin Site.

The way I see it at least, this Central Plugin Site will function much like what Kristine's Plugin Directory does now. It will be a site where people can go to get an official list of available plugins for Movable Type. In addition to what Kristine's site does already, it will also provide MT users with an XML file containing a list of the plugins, which the Plugin Manager will read in.

This XML file will contain:

• plugin names
• authors
• descriptions
• links to information and documentation
• links to the files to download (which would, at the moment, most likely point to the author's site)
• security checks for plugin archive files (just to make sure off-site files have not been tampered with)

I haven't had too much time to work on this lately, between work and school coming up soon. But I have taken a few minutes to tinker with the interface some, to make it look a little more MT-ish. I'll try to get a little more done on the backend this week. I'll also explain a bit more of what Kristine and I have in mind for the central plugin site.

As always, feel free to comment on the plans so far. I want input from the MT community at large for a project like this. :)

Okay, so here's the list I sent Kristine in an email a few minutes ago. I figured I'd make it public just to see if anybody else had any ideas or comments.

Plugin Manager Requirements (i.e. tasks it should perform for the user)

• Lists
  • Get list of plugins from official site
  • List all plugins
  • List installed plugins
  • List non-installed plugins
• Individual Plugins
  • Check plugin requirements (Perl modules and MT version)
  • Install a plugin
  • Upgrade a plugin (when a new version is released)
  • Uninstall a plugin
  • Provide links to plugin information
  • View installed plugin documentation
  • Configure plugin (see: my interface plugins idea)

Any thoughts?

Following through on my earlier idea, I started working on a Plugin Manager/Installer system for Movable Type

Thanks to some work by Kristine to make an XML output file from her Plugin Directory, this Plugin Manager is really starting to come together. Soon, we should be able to have it check plugin requirements, download plugin archives, double check their integrity (to be sure they haven't been tampered with), install the files in the archive, and do any other necessary setup for the plugin. It will also be able to upgrade or uninstall plugins, as well as download updated XML files from a MT Plugin site.

I have lots of plans for this, let's see how many I can actually implement before I get too ahead of myself. :)

I've been kicking it around in my head for a while, so I figured I'd better sit down and write something out before it got too stale. Before I start, I should probably mention that I'm a big fan of FreeBSD's ports system, so that may color my thoughts somewhat.

So, to start with, we first have a central plugin repository, whether it be on movabletype.org, some other site, or some evolution of Kristine's MT Plugin Directory. On this site, in addition to a web-based listing of plugins, with docs, links, etc. But, the heart of the system is the XML version of this site that it makes available to the world.

Now, on the other end of things, in each installation of Movable Type, there lives a little program, which for the time being I'll call the Plugin Manager. When instructed to, this Plugin Manager will query the Plugin Repository for the XML file. It will parse the file, and present the user with a list of available plugins, as well as which ones are installed and which ones can be upgraded. If a user chooses to install/upgrade a plugin, they are informed if they need to install any other plugins or Perl modules first. Once the system is prepared for the plugin, the Plugin Manager follows the link provided in the XML file and downloads the Plugin Archive.

Now, about the Plugin Archive. In this archive, beyond the plugin itself, there are a few support files. An XML file describing the plugin itself and the files is uses (basically an extended version of what is already available on the Plugin Repository site, and which is probably used to build that site as well), a Pre-Install Script, a Post-Install Script, and the Plugin Files themselves. The XML file will be registered/filed in a local repository to be used for an On-Demand Plugin Documentation module in MT. The Pre-Install Script is a Perl scipt eval-ed by MT to prepare for installation of the Plugin. If it fails, the Plugin Files are removed and unregistered with the system. The Post-Install Script is a Perl script eval-ed by MT to setup anything supplemental that the Plugin might need (database tables, or what have you). If that fails, the Plugin Files are removed and unregistered with the system.

And about the On-Demand Plugin Documentation module, the idea there is that a user should have access to documentation for every available tag. They could go into the module and get a listing of every tag available to them, then click on one and get some documentation for that tag, maybe an example, and so on.

So what do you think?

Update: Just wanted to add a couple more thoughts, which I mainly forgot to put in last night. Anyways, The main Plugin XML File on the Plugin Repository Site, which contains links to Archive Files for the Plugins, will also contain MD5 Hashes for those Archive Files for security purposes. Or perhaps something can be worked up with Cryptographic Signatures for the Archive Files. The is all to make sure that the Archive File you download through the Plugin Manager is truly the Archive File you want, and not one containing malicious code.