David Raynes

Andre got in touch with me a couple nights ago with an interesting plugin request. He wanted to be able to have MT automatically send files out via FTP to another host where the web site would actually be living.

So, after about one hour, I had something to send out to him. One hour. I don't want to think about the amount of time I would spend writing something like this in MT 2.x.

It works, but it needs some serious polish and a configuration front-end. Right now, configuration involves hand-editing the plugin, which I try to avoid at all costs when I can. If anybody actually wants to play around with it, let me know and I will make it available.

Here is a quick little mini-plugin that I wrote to help me in the development of the next version of MultiBlog. Comment Callbacks establishes two callbacks for the comment system of Movable Type:

• CommentCallbacks::PostCommentPost which is called right after a comment is first posted
• CommentCallbacks::PostCommentApprove which is called right after a comment is approved

If a comment is approved when it is posted (for whatever reason, be it no comment moderation, TypeKey authentication, etc.), both callbacks are called in the order above.

To install, download one of the following files, unpack it, and place comment_callbacks.pl in your plugins/ directory.

• comment_callbacks-0.1.zip
• comment_callbacks-0.1.tar.gz

As part of an ongoing effort to put together my plugin store, I am looking for some testimonials to use. So, if you have ever used any plugins of mine (especially some of the major ones like MultiBlog/OtherBlog, SubCategories, or one of the pre-release versions of Workflow), I would appreciate it if you could share your experiences, either in a comment or email if you would prefer something less public.

Thanks!

While I would love to do what Jason just did and quit my job and do the blogging and plugin development thing full time, it is just not an option for me right now. We need the health insurance and my steady paycheck now that Jenn is quitting her job.

And since we are going to be losing her income, I need to make sure that all of the work I do outside of my day job is as profitable as I can make it. So I figure I have two options: either drop the blogging and plugin development thing for the time being (if not for good) or start charging for some of my more time consuming plugins and try to find other types of revenue streams I can generate with this site and my plugin work.

I thought I would start the charging with Workflow, and probably MultiBlog 2.0 (not the current version) after that. Everything that has been publicly released up until this point will still be available free of charge. I have also thought about instituting some kind of rayners-plugin subscription idea, where folks could get access to the bleeding edge stuff that I am working on, as well as get first priority for bug reports and feature requests. It is just an idea at the moment though.

I put a lot of time and effort into many of my plugins. And while I have received donations from a number of very generous folks (and I do appreciate it quite a bit; if I do charge, you will all get discounts), the return on my investment of time spent working on all this plugin code is pretty abysmal. With the situation we are entering into now, that is not something that I can afford to continue. Whatever I end up doing, things will be different from now on.

First, there was the monthly archive dropdown featured on Learning Movable Type. I thought it was a great idea, especially since this blog is starting to get a little long in the tooth (not that long, mind you, but long enough that listing all the archives one by one gets to be a page-design issue because of the length involved). It worked perfectly for my monthly archives, but I wanted to involve the category hierarchy I have put together for my categories in the archive list, and with the template code Elise has on her site, the hierarchy would not be reflected.

Maybe it is a point of pride for the guy that wrote the SubCategories plugin and then integrated it into the Movable Type core. Maybe I figure a flat category listing for my blog would not make any damned sense. Either way, I set out to build a dropdown that incorporated the category hierarchy.

So, with Brad's wonderful PerlScript plugin and a new one of my own creation (Category Depth), here's how I do it.

<form action="" name="pulldowncats">
<select name="pulldowncatsselect" onchange="document.location=pulldowncats.pulldowncatsselect.options[selectedIndex].value">
<option value="">Select Category</option>
<MTSubCategories>
<option value="<MTCategoryArchiveLink>">
<MTPerlScript>
print "&nbsp;&nbsp;"x"<MTCategoryDepth>"."<MTCategoryLabel>";
</MTPerlScript>
</option>
<MTSubCatsRecurse>
</MTSubCategories>
</select>
</form>

This is just a quick plugin I wrote to return the depth of the current category. It provides a single tag: MTCategoryDepth.

So download one of the following files, unpack it, and place categry_depth.pl in the plugins/ directory.

• category_depth-0.9.tar.gz
• category_depth-0.9.zip

While talking with Anil a couple days ago, he tossed out an interesting seed idea for a plugin and my mind just took it and ran.

So, here is the basic idea: given one or more feeds (Atom, RSS, etc.), create entries in the local blog based on those feeds. The idea is that you could pull in feeds from Technorati, Flickr, Del.icio.us, other blogs, and anything else that publishes feeds and build entries in your own blog to aggregate that content or whatever else you might want to do with it.

I would write more, but it is late and I just spent a couple hours tracking down a "minor" error in a plugin that I have been playing around with. So, any thoughts?

It all started when I was browsing some local blogs in Bloglines this morning. Among other things, fellow Baltimore blogger, DaBrettman wrote the following about what he did early this morning:

... since I installed MTCloseComments as a plug-in (isn't CloseComments a Raynes creation? Talk about gods of MT development... heh)

Since the ingenious CloseComments plugin is actually the work of Alan Carroll, I took it upon myself to let DaBrettman know. I left a comment on his site mentioning that the plugin was not mine and that he had probably confused it with a quickie script I wrote, which was mostly just a port of a MySQL specific script that somebody else wrote.

Later he responded to my comment thusly:

David: See, I would have worshipped at your altar if you would've just lied a little.. you and your integrity, I swear.

Thanks, DaB. You made my day. :)

So, I was doing some testing on a quickie little plugin that I wrote to help out a reader. It occurred to me that having to create a template and keep rebuilding it while I was testing a single template tag was a little silly. Why not have the ability to just toss the text into a form field, click a button, and get a rendering of that template text? I could write that without too much difficulty.

And then I could add features. Like previews for existing archive templates so that changes could be tested before the entire site is rebuilt. Things like that.

Any other ideas out there?

Almost a week ago, Andre first released TKPal:

TK Pal is a snippet of PHP code you can place in a PHP enabled page to restrict access to content to TypeKey users who have specifically paid to see that content.

So, I have begun writing a wrapper plugin around that so MT users can take it for a spin. This has an enormous amount of future potential.

Just to test it out for myself, and to demonstrate that it works, the link to the plugin code and instructions for installation are in the extended entry, which will cost you $3.50 to access (if you have ever seen that episode of South Park, you will understand where that number came from).

Note: This plugin requires that all the pages in which it is used are output as php.

I should also mention that the fact that you need to pay to access this plugin is meant as a proof of concept only. If you would like, I would be happy to refund the money you paid to get it. All you have to do is ask.

Download one of the following files:

• tkpal-plugin-1.0rc1.tar.gz
• tkpal-plugin-1.0rc1.zip

Unpack it and place tkpal.pl in the plugins/TKPal/ directory, which should have to be created. Once you have done that, get a copy of the TKPal code for yourself, install it in the same directory, and do whatever configuration is necessary.

The following two tags are made available through this plugin:

• TKPalHeader: required if the other tag is to be used, must be placed at the very beginning of the template (i.e. before DOCTYPE declaration, etc.)
• TKPalPremiumContent: container tag to surround the content for which you wish to charge, takes the following arguments:
  • cost: cost for the content
  • link: link for the location of the content, defaults to the permalink for the current entry if there is one

Just a quick update to the ParentCategoryRebuild plugin. This new version fixes the bug that caused archives to be rebuilt even if the entry being saved was not published, and removes the condition that was causing the error message if the entry had no categories selected for it.

Download one of the following files, unpack it, and place parent_rebuild.pl in the plugins/ directory.

• parent-rebuild-1.1.tar.gz
• parent-rebuild-1.1.zip

This plugin will automatically rebuild the category archives for the parent categories of the categories to which an entry has been assigned. The idea is that if you are using MTEntriesWithSubCategories in your category archive templates, you will want those category archives to be rebuilt when an entry is saved. However, the normal behavior is only to rebuild those categories to which the entry is directly assigned. So I ripped the code that performed the parent category archive rebuilding from the last version of the SubCategories plugin, cleaned it up, and here it is.

Download one of the following files:

• parent-rebuild-1.0.tar.gz
• parent-rebuild-1.0.zip

Unpack it, place parent_rebuild.pl in your plugins directory, and you are all set.

( Note: this plugin is using a callback that was introduced in MT 3.1, so it will not work in earlier versions )

Now that I've got the comment situation under control, or so it would seem at least, I am now back to actually thinking about my blog and what I will be doing with it.

Here are some of my current thoughts:

• Incorporate what Jenn has been writing in her journal blog about what we have been going through with the infertility treatments into the main feed for this site, like I have already done with the main index page
• Possibly splitting my blog into two: a Movable Type-only blog, for all my plugins, hacks, experiments, and so forth, and a personal, diary or journal blog. Do any of you folks out there (other than my mother.. Hi Mom!) have any interest in what I'm doing outside of the MT realm? Or maybe want to hear some of what I've been thinking about the infertility stuff, which I have been meaning to write about more?
• I am also trying to find a way to ask folks that have reaped huge benefits from the major time and effort I have put into writing and testing my plugins, which have all be released freely, for maybe a small donation via PayPal, or perhaps a purchase from my Amazon wish-list (or, for you gamers out there, my Games Workshop wish-list). Asking is not the main issue though; asking without sounding like an ass is.

This is as much for all you folks out there as it is for myself. I just wanted to go pick my own brain and write down all that I have told myself that I would work on in the near future. Feel free to make suggestions.

• Polling plugin (significant revamp/rewrite of MTVote most likely)
• Update MultiBlog to handle multi-user environments correctly
• Update ExtendedComments to include changes to the comment process from MT 3.1x
  • Finish up CommentThreads and CommentTitles
• Clean up and release the Apache Authentication for MT "plugin"
• Plenty of work to be done with MT Forge
• Start working on the plugin permissions "plugin" idea

Update: Also needing significant work is the Plugin Manager, but that's more of a long term task. And I am currently not planning on porting any of my plugins to PHP for two main reasons:

• I cannot use the dynamic publishing features myself as I am using Postgres, so testing would be difficult
• The majority of my plugins use data stored with PluginData, which is inaccessible to PHP plugins

Just a quick update for the plugin, incorporating a change Andre made to the Dropcash feeds and adding a pair of new tags: MTDropcashGoalIsReached and MTDropcashGoalIsNotReached

Download:

• dropcash-1.1.tar.gz
• dropcash-1.1.zip

See the Dropcash plugin instructions.

A number of people have reporting having a specific problem with some of my plugins recently (though MultiBlog is the only one I can remember off the top of my head). So, if you are receiving an error message concerning get_config_value, that is because the plugin was written to target MT 3.0D and above. The get_config_value method in those versions of MT was written to make plugin configuration storage and retieval easier.

I could back-port a similar mechanism for MT 2.6x users (it would not be possible for MT 2.5x), but I would rather spend my time beefing up some features that have shown to be lacking (e.g. multi-author sites using MultiBlog). I am tempted to create another feature ransom for the back-porting if people really want it.

The campaign has been more than successful, though it does not currently reflect that as my Paypal account still needs to finish setting up.

So, here is the plugin as I promised.

Download:

• dropcash-1.0.tar.gz
• dropcash-1.0.zip

Unpack it and install dropcash.pl into the plugins/ directory. Tags and instructions can be found at Dropcash Plugin Documentation.

So, based on my earlier thoughts on using Dropcash for feature ransoms, I went ahead and created my own Dropcash fundraiser for a Movable Type Dropcash plugin, if for no other reason than I found it strangely appropriate.

So, when the goal is reached, I will release a plugin (Perl only) for Movable Type that will allow the user to access data on Dropcash fundraisers.

For better or for worse, I have just about given up on the general donation solicitation for all of the free work I do with my plugins. Maybe I am just doing it wrong though. :)

I had a thought this morning. Maybe I could use Dropcash for feature ransoms or something similar. In other words, I could setup a fundraiser for a highly requested feature, and when the monetary goal (which would not be a large one, maybe around $50-$100 or so) of the fundraiser is reached, I would implement the feature.

It's just a thought. What do you folks think?

Update: Looks like Chad has already put up his first feature ransom for MT-Notifier, and from what he tells me, he has already exceeded the ransom. Congrats, Chad!

The following is an email that I sent to some of the folks at Six Apart about two weeks ago. I thought I should share it with the rest of the community.

As we've discussed before, I know that there are corporate customers of yours that are quite anxious for the ability to make use of their existing authentication systems in their blogs. We have also discussed hooking up MT and TypeKey as a start to that, and even developing an LDAP to TK/MT mapping of sorts. For the government customers I see at my day job, and I'm sure plenty of corporate customers as well, relying on something over which they are not in direct control (i.e. TK) is not an option for any number of reasons (e.g. corporate policy, or just not being connected externally at all). Here is my mini-proposal for what I think should be done (and what I would honestly like to do myself).

First, in parallel, support for Apache-based authentication and a native user group/role system need to be implemented. As soon as MT begins allowing in users that did not previously exist internally, the need for a default user configuration becomes apparent. While implementing that as a default set of permissions is an option, it can become a signifcant problem if and when changes to those default permissions need to be changed either for one individual user or for all users. In a small enough installation, it is workable, but in larger organizations being limited to only a single set of default permissions is not going to be an option. All of those problems are avoided by implementing a native group/role system, as one group can be designated as the default group and overall changes can be made to that group to affect everybody, as well changes to individual users can be made without affecting any other group member. In addition, it also sets the stage for the next step.

Finally, support for authentication directly from systems like LDAP/ADS and so forth can be implemented. With the group/role system already implemented, as backend support for external usernames and passwords is added, adding it for the external groups/roles should be relatively simple.

Those are just my thoughts at least. I have already just about implemented the Apache-based authentication, though without any kind of default permissions. I suppose a quick hack could be developed to support that.

And as a bit of an addendum to that, I should also mention that if something like this moves forward, MT will need to move to a more true session handling approach, as opposed to storing the username and password of the current user in a cookie. If nothing else, the group affiliations will need to be cached somewhere else the authentication server will be getting hammered.

I am sure all of you folks who have been using my plugin are dreading having to recreate your category hierarchy now that the code has moved into the MT core. Well, here is a script that I whipped together to migrate your data from the plugin version to the MT core version (as of version 3.1).

Download plugin-to-db.txt, rename it to plugin-to-db.cgi, upload it to your base MT directory, change its permissions so it can be excuted (usually 755), and then run it in your browser. When you are finished, be sure to remove the file from your MT installation.

I have only tested this on my installation as I was upgrading from 3.0D to 3.11, but it worked just fine for me.

Important Note: When upgrading to a 3.1x version of MT, remove all of the files associated with the SubCategories plugin before starting the upgrade.

Movable Type 3.1 Launched

We're happy to announce that this afternoon we released Movable Type 3.1.

We're extremely excited about this new release, and also about how quickly this free update is coming on the heels of Movable Type 3.0 Developer Edition. Whereas it took more than a year between 2.6 and 3.0, we're now releasing 3.1 only three months after 3.0 Developer Edition. The release of 3.0, combined with the changes in licensing, has allowed us to recommit resources to Movable Type development, and that's a big reason why you're seeing major features in a free update released so soon after 3.0.

I have to admit, it is definately a nice feeling to see my name in the announcement as well (emphasis mine).

The new category management interface in 3.1 gives you fine-grained control over the organization and display of your posts. You can easily create new subcategories, and move a subcategory from one parent category to another using a sleak, intuitive interface. Not only that, the subcategory support is extremely powerful, because it builds upon David Raynes' SubCategories plugin and thus inherits all of the tags included in that plugin. David has done a great job helping us integrate the plugin into the core Movable Type engine.

Hopefully this will not be a one-time thing. :)

I am very much looking forward to tinkering with Brad's dynamic templating feature. If for no other reason than to start porting all of my plugins.

The first thing on my to-do list, though, is integration of my ExtendedComments plugin and MT-Blacklist. Now I just need to find the time to do it.

Brad Choate joins Six Apart

While I can't write a post about all our new hires, I wanted to take an opportunity to write about the newest addition to our engineering team, Brad Choate.

So they managed to grab Brad. I all need to do now is finish my cross-country wormhole so that I can commute to SF instead of Annapolis, and I'll be all set. :)

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.

Basically, the idea is to just write a front end for MTMacro. I want it to provide the following features:

• Ability to define macros for use with MTMacro, removing the need for using all the MTMacroDefine tags in your templates
• Ability to test those macros
• Ability to form Macro Groups, which would allow applying a group or groups of macros to any particular instance of MTMacroApply or apply_macros

Of course, this is still very much in the planning stages. And, as always, any feedback, suggestions, comments, or questions are more than welcome.

I know I have previously published a hack that will give you the ability to produce author archives, it just occurred to me that, with the new functionality available to me in MT 3.0, I can write a plugin that will do the same thing, without having to patch the core MT code.

More to come as I develop the idea further. Feature requests are more than welcome.

Since the plugin contest deadline was extended, I thought I would spend some time making more improvements to SubCategories and this is what I came up with.

Download one of the following:

• subcats-1.2.tar.gz
• subcats-1.2.zip

New in this version:

• Category Label Delimeter: When you create a category, you can string together a hierarchy of categorys by putting all the category names in one category and seperating them with the configured delimeter (defaults to '::').
• ( Experimental ) Parent Category Archive Rebuilding: If turned on, when an entry is saved with a primary category set, the category archive for each ancestor of that primary category will be rebuilt.

More information and examples can be found in the SubCategories documentation

Update: Just to make sure I am explicitly clear, these are both MT 3 only features.

Another Update: Okay, a bit of a hiccup on my part. I managed to leave a bug in the Category Label Delimeter code when I moved from the testing version to using the config values (unfortunately, callbacks in MT do not generate immediately obvious errors; you have to go look in the activity log). It has been fixed and the version on the site has been updated. So, if you downloaded it before about 1100 (EDT) on Monday, get it again.

This will be one step towards one of my long-term goals: integration of bug reporting into the MT interface. The screenshot you see is from what I have written so far, which is driven from data coming out of my current GNATS setup. Not all of the fields are visible, but I think you can get the idea. More about this later; I need some sleep.

I think I have finally settled on a bug tracking system that I can use for my plugins: GNATS

The fun thing is that I can completely customize it for use with my plugins, custom fields out the wazoo. So here is a list of fields I am thinking about putting in there. Please feel free to suggest any more you feel might be important.

• Plugin
• Plugin Version
• MT Version
• Bug Type (Bug, Feature Request, etc)
• Severity
• Synopsis
• Description
• Template Code
• Template Output
• Error Message
• Possible Fix/Patch

And for the big important news about this, I am planning on writting a custom MT app/plugin that will allow a user to submit a bug to this system through their own MT interface. That will be very cool.

Okay, the automatic category hierarchy creation feature I mentioned in the previous entry is working and checked into my repository. Next in line is an experimental feature (akin to parts of MultiBlog) that will rebuild category archives for parent categories when an entry is posted to the child category. Testing it is part of the reason that I am writing this right now. :)

Update: It works, for me at least.

I successfully tested a big new feature for SubCategories last night: automatic creation of category hierarchies. This is a MT 3 specific feature. To make use of this feature, you would simply need to create a category containing multiple category names seperated by a specified delimeter (I'll use '::' in this example).

So, if you create this category through the regular MT interface:

Alpha :: Beta :: Gamma

The following category hierarchy will be created:

• Alpha
  • Beta
    • Gamma

Alpha and Beta will only be created if they do not exist already. If both Alpha and Beta do currently exist in the blog, creating a category named Beta :: Gamma would also produce the same result, assuming the relationship between Alpha and Beta have already been created.

One question just occurred to me. Does anybody want to be able to create multiple categories at the same level. For example:

Alpha :: Beta :: Gamma, Delta

• Alpha
  • Beta
    • Gamma
    • Delta

Is anybody out there using the latest SubCategories release on MT 2.x? I just finished helping somebody work on their site and I ended up having to downgrade them to 0.4 (a custom version, though, that I wrote a week or so ago). Unfortunately, debugging CGI is difficult remotely, and plugins are even harder. Please let me know if you are having any problems using SubCategories 1.0 and MT 2.x together.

Okay, so I have been convinced by denizens of #joiito (and I'm sure Zempt users would not mind either) to at least make an attempt to work SubCategories into MT's XML-RPC interface. Unfortunately, I am a little unfamiliar with that technology, as well as MT's implementation of it.

So, while I am learning, does anybody out there have any preferences on how I should work it up? Patch to MT code? New XML-RPC methods? Any suggestions on how the category hierarchy should be returned to the client?

Similar to the Entry plugin, the Category plugin allows you to create a category context in your templates for a specified category.

Download one of the following:

• category-0.5.tar.gz
• category-0.5.zip

Install:

• category.pl in the plugins/ directory

It currently provides only one tag, MTCategory. MTCategory takes a single argument: name, which should be fairly self explanitory (documentation).

On a side note, part of me is tempted to put the Entry and Category plugins together, add in a few more tags for the rest of the MT entities, and release that as one plugin whose name I have not yet determined. What do you think?

SubCategories 1.0 is here! And there was much rejoicing. (Yay!)

You can download it here:

• subcats-1.0.tar.gz
• subcats-1.0.zip

Some of the more significant changes from the previous release (0.4):

• Much much improved interface (specially designed to make use of MT 3.0's CSS)
• Significant clean-up of the code
• Addition of the rayners::SubCategory API for other plugin developers
• Improved interface
• New tags: MTTopLeveParent, MTIfIsAncestor, MTIfIsDescendant
• Fixed a number of nagging bugs
• MTSubCategories (and MTTopLevelCategories): setting sort_order to 'descend' actually works correctly now
• MTSubCategories (and MTTopLevelCategories): new attribute sort_method allows you to define a custom category sorting method
• MTSubCatsRecurse: new attribute max_depth gives you control over how deep into the category hierarchy you want to go in your template
• Did I mention the improved interface?
• Should still be compatible with MT 2.x (not extensively tested though)
• MT 3.0 feature: when a category is removed via the MT interface, it is also removed from the hierarchy (i.e. the parent of its children will be set to its parent). If you are still using MT 2.x, those children will be listed as orphaned categories in the interface.

Be sure to read the SubCategories documentation for installation instructions and complete template tag and API documentation.

I spent a very large amount of time fixing bugs, implementing features, and just adding polish to this new version of SubCategories. If it proves useful to you, you might want to consider donating or purchasing something on my Amazon wish list (links coming shortly). I very much enjoy working on all my plugins, and I make them available for free, but they do take up a great deal of my time.

Enjoy!

It is 2am and I have been coding, tweeking, and debuging SubCategories for the last few hours. Unless I have any more feature ideas over the next day, or find any bugs, SubCategories Version 1.0 will be released tomorrow evening (East Coast Time).

I hope everybody appreciates the enormous amount of work I have put into making this release as robust and useful as possible.

I have made the decision to maintain documentation for all of my plugins in a wiki. Part of me wants to try to do it in the blog, but that is becoming impractical (plus a wiki makes it easier to recruit others to help out). I will still continue to make development news and release announcements here, but the documentation will be kept in the wiki I have setup. So far, all that has been created is the documentation for SubCategories, but more will be coming in the next few weeks as I find the time.

Barring any bugs, this release candidate will become the official 1.0 release of the SubCategories plugin.

Changes from the last release candidate:

• POD documentation for rayners::SubCategory
• Added IfIsAncestor and IfIsDescedant tags
  • IfIsAncestor takes one argument, child, and will return true if the category child is below the current category in the hierarchy.
  • IfIsDescendant takes one argument, parent, and will return true if the category parent is above the current category in the hierarchy.

Download one of the following files:

• subcats-1.0rc4.tar.gz
• subcats-1.0rc4.zip

The files need to be installed as follows:

• sub_cats.pl: in the plugins/ directory
• mt-sc.cgi: in the base MT directory, and be sure its permissions are set correctly (chmod 755)
• SubCats.pm and SubCategory.pm: in extlib/rayners/

Changes from the previous version of the Entry plugin:

• Finally tested on MT 3.0 (works just fine)
• Added the ability to select the first or last entry by specifying the id as 'first' or 'last'

<MTEntry id="first">
First entry in the blog here.
</MTEntry>

<MTEntry id="last">
Last entry in the blog here.
</MTEntry>

True, the 'last' effect can be achived using MTEntries with lastn equal to 1, but trying to get to the first entry of the blog with MTEntries does not work (i.e. you can either set lastn equal to 1 or sort_order to ascend, but not both). Since I was implementing the 'first' ability, I figured I might as well include the ability to get the last entry as well. It was only two more lines of code. :)

Download one of the following:

• entry-0.5.tar.gz
• entry-0.5.zip

And install entry.pl into your plugins/ directory.

As you may see if you look at the comment pages on this site, you can now reply to a specific comment and it will be displayed as such when you submit your comment.

So, CommentThreads is working now. I just need to clean it and ExtendedComments up before releasing them to the public. Should only be a couple more days. Until then, here is the template code I am using on my site to display the comment threads, just to give you a taste (edited slightly for display purposes):

<MTCommentThreads>
<MTCommentThreadsIfFirst><ul></MTCommentThreadsIfFirst>
<li><div class="comment">
<a id="c<$MTCommentID$>"></a>
<h4><MTCommentTitle use_default="1"></h4>
<div class="posted">
<p class="posted">&raquo; <$MTCommentAuthorLink spam_protect="1" 
no_redirect="1"$> at <$MTCommentDate$>:</p>
<p>[ <a href="<$MTCGIPath$><$MTCommentScript$>
?__mode=preview
&entry_id=<MTEntryID>
&parent_id=<MTCommentID>
&static=1">Reply to this</a> ]</p>
</div>
<$MTCommentBody$>
</div>
<MTCommentThreadsRecurse>
</li>
<MTCommentThreadsIfLast></ul></MTCommentThreadsIfLast>
</MTCommentThreads>

There is a bug in Movable Type: only single values (i.e scalar references) can be stored with MT::PluginData when used with a PostgreSQL database. Complex values (i.e. non-scalar references) can be stored with MySQL however, because MySQL allows binary data in its text columns (I would consider that incorrect behavior myself). PostgreSQL does not. So, to fix the problem, the binary data that the Storable perl module outputs needs to be converted to text before reaching the database. To do this, I made use of pack and unpack to trasform the data to and from hexadecimal before it gets to the database itself. I also needed to be sure to preserve any existing data already stored in the database.

The updated data method of MT::PluginData looks like this:

sub data {
    my $data = shift;
    $data->column('data', unpack ("H*", freeze(shift))) if @_;
    my $r;
    eval {
        $r = thaw($data->column('data'));
    };
    $r = thaw(pack ("H*", $data->column('data'))) if ($@);
    $r;
}

Changes from 1.0 Release Candidate 2:

• Fixes a couple major bugs
• Added a new container tag: TopLevelParent which resolves to the highest parent category for the current category

Download one of the following files:

• subcats-1.0rc3.tar.gz
• subcats-1.0rc3.zip

The files need to be installed as follows:

• sub_cats.pl: in the plugins/ directory
• mt-sc.cgi: in the base MT directory, and be sure its permissions are set correctly (chmod 755)
• SubCats.pm and SubCategory.pm: in extlib/rayners/

(Okay, so release candidate 1 was pretty short lived)

Here is a release candidate for SubCategories, with added support for the new functionality available in Movable Type 3.0 (though it should be compatible with MT 2.x, but I have not tested it), along with a significantly improved user interface and an API for other plugin developers.

Download one of the following files:

• subcats-1.0rc2.tar.gz
• subcats-1.0rc2.zip

The files need to be installed as follows:

• sub_cats.pl: in the plugins/ directory
• mt-sc.cgi: in the base MT directory, and be sure its permissions are set correctly (chmod 755)
• SubCats.pm and SubCategory.pm: in extlib/rayners/

There are a couple more minor feature additions I need to make, and the SubCategory API needs to be documented. Other than that, however, it is pretty much it its final state. Hopefully there will not be too many bugs to fix. :)

ExtendedComments and CommentTitles are coming along well so far. I am still working up the preview portion of the comment system, but as long as you just go ahead and post, it is working just fine. Once I get preview working, CommentThreads should follow up shortly afterwards.

Update (at 1:40 on 06/08): Okay, so I got preview working now. I was expecting it to go quickly, but not that quickly.

Just to help me think things through, I am in the process of porting code from the provided MT::App::Comments class to "work" with my planned rayners::ExtendedComments class. I plan on making each and every feature available in the default comments script work as a plugin of sorts with my new script.

For example, here is the current code for the callback that operates on the entry_id parameter. It will most likely be setup as one of the first callbacks used when creating a comment. If it errors out, the process is halted and no comment is created. Otherwise, it will continue to the next callback, which can error out and halt the process there, and so on.

sub entry_id_param {
  my ($app, $comment, $entry_id) = @_;

  require MT::Entry;
  my $entry = MT::Entry->load ($entry_id) or
    return $app->error ($app->translate (
          "No such entry '[_1]'.", $entry_id));
  return $app->error($app->translate(
        "No such entry '[_1]'.", $entry_id))
    if $entry->status != RELEASE;

  unless ($entry->allow_comments eq '1') {
    return $app->handle_error($app->translate(
          "Comments are not allowed on this entry."));
  }

  $comment->blog_id ($entry->blog_id);
  $comment->entry_id ($entry_id);
  $comment;
}

What I am working towards is a setup where each of the current features of MT::App::Comments is replicated in rayners::ExtendedComments so that adding on new features (e.g. CommentTitles) will be fairly trivial.

Recently, I have been talking with Imajes in #joiito about the port of a site to MT. This site currently has a threaded comment system, and he was looking to see if it was doable in MT. Currently, the only way to do it is via a hack, MTThreadedComments, but I thought there might be a better way to do that, especially after all the experience I have gained while working on the SubCategories plugin. So, I am going to announce the following plugins:

• ExtendedComments
• CommentTitles
• CommentThreads

ExtendedComments

ExtendedComments, as a replacement for mt-comments.cgi, will not be so much a plugin as it will be a platform for plugins. The idea here is to give plugin authors a way to add functionality to the comment system without having to write yet another MT::App class.

I envision something like the following being used in a plugin to add a handler for a new argument to the ExtendedComments cgi script:

rayners::ExtendedComments->add_param ('param_name' => \&handler);

CommentTitles

CommentTitles will provide what you would expect, titles for comments. Mostly, it is to duplicate functionality of the MTThreadedComments hack, as well as to provide me with a very basic plugin with which to test ExtendedComments.

CommentThreads

Here is the fun part. CommentThreads will provide a threaded comment system for MT users, without having to resort to patching the core files.

All three of these are still very much in the preliminary planning stages, so any and all feedback is more than welcome.

Just to make sure everybody is aware of it, I am taking steps to make sure that the next release of SubCategories will be compatible with both MT 2.x and 3.0.

And here is a preview of the new and improved interface.

Here is what I have come up with so far. Please let me know if there is anything more I can provide.

rayners::SubCategory will extend the MT::Category class and provide the following additional methods:

• has_parent: Returns the id value of the parent (0 if the category has no parent)
• has_children: Returns true if the list of children for the category is defined
• children_categories: Returns the list of immediate children categories (i.e. only the children on the next level down) as rayners::SubCategory objects
• is_ancestor: Returns true if the category is an ancestor of the given category (e.g. true if $parent->is_ancestor ($child))
• is_descendant: Returns true if the category is a descendant of the given category (e.g. true if $child->is_descendant ($parent))

Here is some Perl code that can be used to integrate this with a plugin:

my $category_class = "MT::Category";
my $subcategories_available = 0;
eval {
    require rayners::SubCategory;
    $category_class = "rayners::SubCategory";
    $subcategories_available = 1;
};

my $cat = $category_class->load ($some_category_id);

Any thoughts, questions, or concerns?

I have decided to try and provide an interface to the SubCategories data for other plugin programmers (mostly because I want to use it in MultiBlog). Other than a method that will return the category hierarchy itself, are there any other methods anybody would like to have available?

Well, I just finished my initial testing and everything is working just wonderfully. Hopefully I will have things cleaned up and packaged nicely very soon. The External-Auth "plugin" will allow MT site administrators to use Apache's robust built in authentication mechanisms to give people access to MT. For example, I've logged into MT tonight via the following setup in Apache with mod_auth_pgsql :

AuthType Basic
AuthName "Rayners MT Install"
Require valid-user
Auth_PG_host localhost
Auth_PG_port 5432
Auth_PG_user mt_auth
Auth_PG_pwd  password
Auth_PG_database  access_control
Auth_PG_pwd_table mt_auth
Auth_PG_uid_field username
Auth_PG_pwd_field password
Auth_PG_hash_type md5

So, by adding a user into the user table in my access_control database and assigning the right permissions (in this case, in my system_user_access table), which makes the user visible in the mt_auth view, I could give this user access to MT without:

• Manually adding them to the MT system
• Having to maintain two passwords (or more if other systems are involved)

This currently does involve a minor edit to any MT application for which you would wish to use such an access control scheme (just adding/changing two lines). There probably is no way around that for the time being.

(One side note, as this will probably be not so useful for Joe Blogger, I will most likely make this available under a for-pay commercial-use license, but if there is enough interest, I am willing to consider a low-cost personal-use licence. No final decisions one way or the other have been made yet though.)

After reading what Scott wrote, I took a look into the code and documentation for MT 3.0, and it turns out that my Optional-Redirect plugin is of no use with the new version of MT. MTCommentAuthorLink now supports the no_redirect argument to turn off the redirection "feature".

For example:

<$MTCommentAuthorLink no_redirect="1"$>

I have sent out the second beta version to the testers. Significant improvements have been made to the plugin.

• Major UI improvements, including some JavaScript and the ability to unset the parent category of a child category (which was much requested).
• (New for MT 3.0) When a category is removed from MT, it is first removed from the category hierarchy.

Assuming testing goes well, a public version should hit the streets in a week or two.

Just for the heck of it, I have decided to start hanging around in #mt-plugins on irc.freenode.net. It's not an official channel at the moment, but if others start coming in, I will take that step. I figure I can do a little real-time plugin support there, along with gathering up ideas and suggestions for new and current plugins.

Well, after staying up later than I probably should have, I seem to have a working version of SubCategories in MT 3.0D. I'll spend some time cleaning it up tomorrow and letting the volunteer beta testers, if there are any left now, take a whack at it while I start integrating some of the new MT 3.0 plugin features.

With MT 3.0 coming soon, I figure I should take the time to go through each and every one of my plugins and give them a thorough looking-over and scrubbing if necessary. At least make sure that they will not crash any MT 3.0 install. And update them to hopefully take as much advantage as possible of the new features coming down the pipe in MT 3.0. Basically I want to certify each of my plugins for MT 3.0.

To do this, I will need a number of willing guinea pigs volunteers (who, for the time being, have access to the beta). In return for their willingness to place their hard earned blogs in jeopardy, I promise to:

• Give them access to bleeding edge plugin code not available to the public yet
• Give their bug reports and feature requests highest priority
• Free stuff! (Okay, so I am not sure about that one, but if I ever do charge for plugins, they would not be charged as much if at all)
• Any other suggestions?

I imagine coordination would be done over a mailing list or web forum, along with a bug/feature request tracker and other fancy engineering software. And maybe I will toss in an IRC channel to boot. Who knows?

Anybody want to step forward?

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.

• New Tags:
  • MTHasNoSubCategories: the opposite of MTHasSubCategories
  • MTHasNoParentCategory: the opposite of MTHasParentCategory
  • MTTopLevelCategories: a container tag that acts just like MTSubCategories, except that it will always start at the top category level, instead of the current category if there is one
• New Attributes:
  • MTSubCategories (and MTTopLevelCategories) : sort_order: set to 'descend' to sort the categories in reverse order

Download the new version here:

• sub_cats-0.4.tar.gz
• sub_cats-0.4.zip

I have finally gotten around to cleaning up the quickie update I did to help out the Blog for America folks.

So, here is a summary of the changes in this version:

• Bugfixes:
  • Changed time difference checking to look for difference >= 0 instead of just difference > 0. This may have caused some odd behavior when time differences fell on exact boundaries.

• New Attributes:
  • MTCountdown / MTCountup : count_only
    • A list of the specific time periods to check, seperated by a commas (e.g. "years,days,hours")
    • Only periods from the following list will be considered:
      • years
      • weeks
      • days
      • hours
      • minutes
      • seconds
    • Important: The time periods will be counted in the order they are given. If you put 'days' before 'years', the 'days' counter will gobble up all the time before checks for 'years' are performed.

Download it here:

• countdown-0.4.tar.gz
• countdown-0.4.zip

Note: I know I have been asked this before, so I would like to head off the feature requests right now. I currently have no plans to incorporate 'months' into the list of periods checked, as months do not have a fixed length. If somebody else wants to put together the code to do that calculation, I would be happy to integrate it into the plugin, but I do not plan on doing it myself.

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!

Just a quick update to fix the problems people have been having with the initial release. Enjoy!

• optional_redirect-0.1.1.tar.gz
• optional_redirect-0.1.1.zip

It's baaack. :)

I have finally brought the plugin in line with the new version of the site (mostly just updating a few of the regular expressions). I will be adding new features soon, but this version will work well enough for now.

Here is the summary of the tag changes:

• Removed MTBlogSharesTotalBonds
• Removed MTBlogSharesTotalProjected
• Removed MTBlogSharesTotalReal (long ago replaced by MTBlogSharesWorth)
• Added MTBlogSharesCashBalance for total cash balance
• Added MTBlogSharesTotalMarket for total market orders
• Added MTBlogSharesTotalIdeas for total ideas commodities

Please refer to the documentation in the original MTBlogShares until I can write up something newer while I start adding features in the coming weeks.

• blogshares-0.6.tar.gz
• blogshares-0.6.zip

Thanks to some updates from Bjoern Graf, the following has been changed:

• Bugfixes:
  • Fix in the builtCatHeir method
  • Fixed bug in MTParentCategory: problem picking up on category in a category archive
  • Fixed bug in MTEntriesWithSubCategories: misbehavior when used in category archive

• New tags:
  • MTHasSubCategories: conditional tag that returns true if the current category has categories beneath it
  • MTHasParentCategory: conditional tag that returns true if the current category has one or more categories above it

• sub_cats-0.3.tar.gz
• sub_cats-0.3.zip

Enjoy!

I upgraded to MT 2.661 now, but I was not too sure about whether I wanted to use the new redirect "feature" for the MTCommentAuthorLink, so I wrote up this little plugin. Install it like any other plugin, and the MTCommentAuthorLink tag now takes a new argument, redirect. If set to 1, the redirect feature is used, otherwise, the old style behavior is used (I ripped the code directly out of MT 2.64).

• optional_redirect-0.1.tar.gz
• optional_redirect-0.1.zip

This is just a minor bug-fix release. SubCategories should now correctly recognize the category when it is used in a category archive template.

• sub_cats-0.2.1.tar.gz
• sub_cats-0.2.1.zip

Enjoy!

Here are some big updates to the SubCategories plugin:

• Caches category hierarchy to improve rebuild times (thanks Brad)
• Updated web interface based on changes from Wai Siow
• Added a number of checks to interface
  • Category cannot be its own parent
  • Categories must be in the same blog
  • Permissions to edit categories must be present
  • Attempt to prevent cyclical hierarchies
• Added/Changed the following tags:
  • MTParentCategories:
    • Added exclude_current argument, to exclude the current category from the list
  • MTParentCategory:
    • Container tag for only the immediate parent of the current category
  • MTSubCategories:
    • Added include_current argument, to include the current category in the list
  • MTSubCategoryPath:
    • Based on Brad's suggestion, this is a short-cut tag for the following template code:

<MTParentCategories glue="/"><MTCategoryLabel dirify="1"></MTParentCategories>

Download from here:

• sub_cats-0.2.tar.gz
• sub_cats-0.2.zip

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.

Based on what Jeremy has worked up already, I have created a small little MT application that will close the entry to comments (and pings if you so desire) for any entries older than a given number of days (defaults to five).

So, download one of the following, unpack it, and place mt-close.cgi in your base MT directory. Be sure to set the permissions of the file so that it can be executed.

• mt-close.tar.gz
• mt-close.zip

Then, to use it, just bring up http://your.mt.url/mt-directory/mt-close.cgi in your browser of choice.

Enjoy!

Update: (2003-12-27 12:10)

The bug Neil found is now fixed. Just download the script again.

Before I go and do anything drastic, I thought I would pose this question to the community at large: would anybody out there be interested in gaining read-only access to my plugin source code repository (including the Plugin Manager)?

Right now, I am just using CVS on my personal machine, but I have been thinking about setting up Subversion (CVS's successor) on my server machine.

So, does anybody out there want access?

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.

While cobbling together an Atom implementation for MovableType, I've had to change how passwords are stored. After a quick email from Mark, I changed lib/MT/Author.pm slightly to make the passwords stored in a manner more friendly to the current Atom Authentication Scheme, and allow easy migration of current passwords.

Here is the diff:

--- Author.pm.old       Thu May 29 00:04:58 2003
+++ Author.pm   Thu Sep 11 09:13:48 2003
@@ -6,6 +6,8 @@
 package MT::Author;
 use strict;

+use Digest::SHA1 qw( sha1_hex );
+
 use MT::Object;
 @MT::Author::ISA = qw( MT::Object );
 __PACKAGE__->install_properties({
@@ -25,9 +27,8 @@
 sub set_password {
     my $auth = shift;
     my($pass) = @_;
-    my @alpha = ('a'..'z', 'A'..'Z', 0..9);
-    my $salt = join '', map $alpha[rand @alpha], 1..2;
-    $auth->column('password', crypt $pass, $salt);
+    $auth->column ('password',
+       sha1_hex (join (':', $auth->column ('name'), 'MovableType', $pass)));
 }

 sub is_valid_password {
@@ -35,8 +36,15 @@
     my($pass, $crypted) = @_;
     $pass ||= '';
     my $real_pass = $auth->column('password');
-    return $crypted ? $real_pass eq $pass :
-                      crypt($pass, $real_pass) eq $real_pass;
+    return 1 if ($crypted ? $pass eq $real_pass :
+       sha1_hex (join (':', $auth->column ('name'), 'MovableType', $pass))
+       eq $real_pass);
+    if (crypt ($pass, $real_pass) eq $real_pass) {
+      $auth->set_password ($pass);
+      return 1;
+    }
+
+    return 0;
 }

 sub remove {

You have probably all seen the Comment Queue hack over at scriptygoddess. Well, a couple nights ago Cheyenne asked me to install it for her, as she has been having troll problems lately.

The Comment Queue script requires PHP and a MySQL backend and gnome-girl.com is not using a MySQL backend. Needless to say, it would be a chore and then some to migrate her site to MySQL. So, as you may have heard if you read her site, I quickly threw together a perl version for her to use, and I thought I would release it to the general public now. The interface leaves a little (okay, quite a bit) to be desired, but it works.

So, if you want to use it, after you perform the changes to the MT files and database (only if you are using MySQL) as described in the hack, just download one of the following files, unpack it, and place mt-comments-pending.cgi in your base MT directory. Be sure to chmod it to 755 so it can be executed.

• comment_q.tar.gz
• comment_q.zip

Here it is. Download one of the following files, unpack it, and place sub_cats.pl in your plugins/ directory and mt-sc.cgi in your base MT directory. mt-sc.cgi will probably need to be chmod'ed to 755 so it can be executed.

• sub_cats.tar.gz
• sub_cats.zip

It provides the following tags:

• MTSubCategories: a MTCategories replacement that handles the sub-categories you define
  • MTSubCatIsFirst: True if this is the first category in the current context
  • MTSubCatIsLast: True if this is the last category in the current context
  • MTSubCatsRecurse: use the current MTSubCategories container on the next lower level of categories (i.e. the sub-categories of the current category)
• MTParentCategories: a container tag that starts with the top-most parent of the category and loops its way down
  • glue: the text to use to tie the list together
• MTEntriesWithSubCategories: replacement for MTEntries that handles sub-categories
  • category: if the defined, it will select entries either in that category or in any of its sub-categories
  • any other arguments act exactly like MTEntries

Here are some usage examples that I've been using on my site:

Category List

<MTSubCategories>
<MTSubCatIsFirst><ul></MTSubCatIsFirst>
<li>
<MTCategoryLabel>
<MTSubCatsRecurse>
</li>
<MTSubCatIsLast></ul></MTSubCatIsLast>
</MTSubCategories>

Category Archive File Name (e.g. category/sub-category/sub-category/index.php)

archives/<MTParentCategories glue="/"><MTCategoryLabel
dirify="1"></MTParentCategories>/index.php

Category Breadcrumbs for an Entry

<MTEntryCategories glue=", ">
<MTParentCategories glue = "-&gt; ">
<a href="<$MTCategoryArchiveLink$>"
   title="<$MTCategoryDescription$>"><$MTCategoryLabel$></a>
</MTParentCategories>
</MTEntryCategories>

I also replaced all the MTEntries containers in my Category Archive Template with MTEntriesWithSubCategores to include all the sub-categories for the given category. You can also use the category list example in your Category Archive Template to produce a list of sub-categories.

To define how your categories relate to each other, just load up mt-sc.cgi in your web browser. With the dinky little interface I threw together, you can define the category -> sub-category relationship for your categories. The code will make sure that you do not define a category to be a sub-category of itself, but there are currently no safeguards against creating a sub-category loop (e.g. A is a sub-category of B which is a sub-category of A). If one of those is created, MT may get stuck in an infinite loop during your rebuilds (and therefore fail when the usual CGI timeout is hit).

Hopefully some (maye even most?) of that made sense. If you do not understand any part of this, please let me know and I will try and explain things more thoroughly.

( Note: This requires MT 2.6 or higher, and uses MT::PluginData, so the Storable perl module must be installed by your host )

Update: (2003-09-24 06:54)

I have added in some extra functionality to mt-sc.cgi thanks to Jay. Now it will print out a quick category heirarchy while you are editing. I still need to implement some kind of loop checking though. Anyways, enjoy!

Ben requested this a while ago, and I finally got a chance to sit down and write it tonight. PluginManagerTags provides a set of tags you can use in your templates to access data that the Plugin Manager stores.

Download one of the following files, unpack it, and place pm_tags.pl in your plugins/ directory:

• pm_tags.tar.gz
• pm_tags.zip

The following tags are available:

• MTInstalledPlugins: container tag that provides you with a list of the installed plugins (as far as the Plugin Manager is aware)
• MTPluginName: the name of the installed plugin
• MTPluginVersion: the installed version of the plugin

Usage Example:

<ul>
<MTInstalledPlugins>
<li><MTPluginName> (<MTPluginVersion>)</li>
</MTInstalledPlugins>
</ul>

For those of you that actually visit my site (as opposed to reading my feed), you may have noticed something unusual appear over the last few days. Well, I'd like to take a moment to explain what's going on. I am finishing up development and testing of a plugin that will give MT sub-category-like functionality. Certainly, it's not perfect, but it seems to be doing the job pretty well so far.

So, if you've got any particular requests for what a SubCategories plugin should do, please let me know. Assuming I've got most of the major issues worked out already, I should have a releasable version out by tomorrow night.

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.

With the latest release of my Countdown plugin, I had a neat idea that I figured I'd share with everyone.

So, here's a quick way to display how long your blog has been around, with the Countdown and Entry plugins:

This blog has been up for <MTEntry id="1">
<MTCountup date="[MTEntryDate format='%Y-%m-%d %H:%M:%S']">
<MTCountupIfYears>
<MTCountupYears> years, 
</MTCountupIfYears>
<MTCountupIfWeeks>
<MTCountupWeeks> weeks, 
</MTCountupIfWeeks>
<MTCountupIfDays>
<MTCountupDays> days,
</MTCountupIfDays>
<MTCountupIfMinutes>
<MTCountupMinutes> minutes,
</MTCountupIfMinutes>
<MTCountupIfSeconds>
<MTCountupSeconds> seconds
</MTCountupIfSeconds>
</MTCountup>
</MTEntry>

Obviously you do not have to use the Entry plugin, you just need a way to select the first entry in your blog. I recall seeing a way to do it with the SQL plugin, but I think this way just looks cleaner. Or maybe I am just weird. :)

It could also be trimmed down quite a bit too. You do not have to use all the MTCountupIf tags like I did.

I've been meaning to implement this for a while, but I only just now got around to it. MTCountdown provides a set of tags that will allow you to place a countdown timer in your MT templates.

Download one of the following files, unpack it, and place countdown.pl in your plugins/ directory.

• countdown.tar.gz
• countdown.zip

The following tags are available:

• MTCountdown: container tag that takes one argument, until, in the following format: YYYY-MM-DD HH:MM:SS
• MTCountdownIfYears / MTCountdownIfDays / MTCountdownIfHours / MTCountdownIfMinutes / MTCountdownIfSeconds: conditional tags that return true if there is a positive value for years, days, etc.
• MTCountdownYears / MTCountdownDays / MTCountdownHours / MTCountdownMinutes / MTCountdownSeconds: the values calculated for the countdown timer.

Usage Example (counting down to my birthday):

<MTCountdown until="2003-05-13 14:00:00">
<MTCountdownIfYears><MTCountdownYears> years, </MTCountdownIfYears>
<MTCountdownIfDays><MTCountdownDays> days, </MTCountdownIfDays>
<MTCountdownIfHours><MTCountdownHours> hours, </MTCountdownIfHours>
<MTCountdownIfMinutes><MTCountdownMinutes> minutes, </MTCountdownIfMinutes>
<MTCountdownIfSeconds><MTCountdownSeconds> seconds</MTCountdownIfSeconds>
 until my birthday.
</MTCountdown>

Update: (2003-06-07 01:10)

• Added tags for weeks ( MTCountdownIfWeeks and MTCountdownWeeks ).

Update: (2003-06-23 21:51)

• Added new MTCountup tags (they work just like MTCountdown, but counting from a past date)
• To make things a little less confusing, MTCountdown and MTCountup both take the date argument now (instead of until)
• date can now include embedded MT tags (e.g. [MTTag ...])

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

Starting with an idea I got while reading a thread on the MT Support Forums, I started working on a new plugin: MTBlogPings .

It doesn't do much just yet, but I imagine I'll be adding more features to it in the future.

Download one of the following files, unpack it, and place pings.pl in your plugins/ directory.

• pings.tar.gz
• pings.zip

It provides the following tags:

• MTBlogPingCount
  • Returns the number of pings the blog has received in total

Future Plans:

• Adding an MTPing tag, in the same form as MTEntry
• Feel free to suggest any more ideas...

Update: (2003-05-13 17:15)

• Added a new container tag, MTBlogPings, which acts like MTPings, except that you can give it lastn, offset, and tb_id (the number in your trackback urls) arguments. If given a tb_id, MTBlogPings will only return pings to that specific id.
• MTBlogPings will also import either the Category or Entry that was pinged, so you can use all of the MTEntry* and MTCategory* tags.
• Within MTBlogPings, you can use the two new conditional tags ( MTBlogPingsIfEntry and MTBlogPingsIfCategory ) to determine whether the trackback was sent to a Category or an Entry, so you can determine the appropriate tags to use.

Update: (2003-06-05 16:58)

• MTBlogPings can now take one additional argument, category.
• MTBlogPings is now aware of Category contexts (e.g. with the MTCategories tag) and will return Trackbacks for that Category.

Update: (2003-06-09 15:26)

• MTBlogPingCount can now take a category argument as well. It will return the number of pings to that Category.

I wrote this plugin because I was feeling lazy. I did not want to track down the titles for all the pages I have linked to, so I wrote a plugin to do it for me. Introducing MTLinkTitles.

Download one of the following files, unpack it, and place link_titles.pl in your plugins/ directory.

• link_titles.tar.gz
• link_titles.zip

Usage example:

<MTEntryBody link_titles="1">

link_titles

• When this filter is applied, any anchor tag (i.e. <a href="blah blah">) that appears in the resulting text will be visited to gather the title of the page, which will then be added to the tag itself (e.g. title="Page Title").
• The titles will be cached with MT::PluginData so that once a title is found, no further HTTP requests need to be made. If the title has changed and you would like to get the new one, just browse through the mt_plugindata table and delete the row with MTLinkTitles as the plugin value and the URL as the key.
• If that doesn't work well for everybody, I'd be willing to work up another cache-clearing method.

Update (2003-06-08 11:27)

• No, this will not override existing title attributes.

I've been pretty fascinated by what's going on at BlogShares lately, so I figured I'd write a little plugin I could use to access my blog's current value.

And here it is. It's not much of a plugin so far, it's mostly just a little hack to download the tracking page for the current (or a given) blog and throw a couple of perl patterns at the results to pull out the data.

Download one of the following files, unpack it, and place blogshares.pl in your plugins/ directory.

• blogshares.tar.gz
• blogshares.zip

It provides the following tags:

• MTBlogShares
  • container tag
  • takes one optional argument, blog_url, to specify the url to check at BlogShares, which defaults to the url of the current blog
• MTBlogSharesPrice
  • The blog's current stock price
• MTBlogSharesPE
  • The blog's current P/E ratio

Usage Example:

<MTBlogShares>
Price: <MTBlogSharesPrice><br />
P/E Ratio: <MTBlogSharesPE><br />
</MTBlogShares>

Minor Update: (2003-04-02 13:54)

• Changed the behavior of MTBlogShares. If there is a problem contacting the BlogShares site, MTBlogShares now returns an empty string instead of erroring out. That should fix most people's problems with the plugin and the state of the site at the moment.

Update: (2003-04-04 13:46)

• I added a new container tag, MTBlogSharesUser, that can be used to access data for your account (instead of for your site). It takes one required argument, id, for your user id at BlogShares.
• Within MTBlogSharesUser, you can use the MTBlogSharesTotalPortfolio to access the total vaue of your portfolio.
• I may add other tags this weekend (including what stocks you own, etc), but that's a bit more of a hassle when you're just download a webpage. Hopefully Seyed and I can get the XML spec worked out this weekend, which would a) speed the use of the plugin up some, and b) give me very easy access to the data (instead of having to toss some regular expressions at an HTML page). Cross your fingers.

Usage Example

<MTBlogSharesUser id="1615">
My portfolio is worth $<MTBlogSharesTotalPortfolio>
</MTBlogSharesUser>

Update: (2003-04-20 00:25)

• Changes at BlogShares caused this plugin to break. I fixed it.
• I hope to be including support for some of the new features that Seyed has added recently.

Update: (2003-04-20 02:23)

• I added the following tags to the plugin by request :
  • MTBlogSharesAvailable
  • MTBlogSharesOutgoingLinkValue
  • MTBlogSharesMarketShare
• Working on adding a share owners list to the plugin, but it is proving more difficult than I expected.

Update: (2003-04-22 15:37)

• I fixed the problem with the total portfolio tag. Seems Seyed went ahead and put some crazy things on the BlogShares pages, like commas in the dollar amounts. :)

Update: (2003-04-25 02:56)

• Finally added shares owners to the plugin. To access them use the following tags:
  • MTBlogSharesOwners: container tag for the share owners
  • MTBlogSharesOwner: the share owner's name
  • MTBlogSharesOwned: the number of shares owned

Usage Example:

<MTBlogShares>
<MTBlogSharesOwners>
<MTBlogSharesOwner> owns <MTBlogSharesOwned> shares<br />
</MTBlogSharesOwners>
</MTBlogShares>

Update: (2003-05-01 13:04)

• The changes to the site broke the plugin again. I am working to fix the problem.

Big Update: (2003-05-01 13:18)

• The changes have been incorporated into the plugin. Everything should be working again. If not, please let me know. I'll look into adding some new features when I get home later tonight. But, for now, I need to get back to actual paying work. ;-)

Another Big Update: (2003-05-01 23:52)

• To celebrate the site going out of beta, I've implemented the following general tags for MTBlogShares:
  • MTBlogSharesTotalBonds
  • MTBlogSharesTotalProjected
  • MTBlogSharesTotalReal
• And I've added a new container tag: MTBlogSharesUserRSS. it acts much like MTBlogSharesUser, except that it uses the portfolio RSS feed instead of the user page. If you do not have the XML::RSS perl module available, it and the following tags will not be available.
  • MTBlogSharesUserStocks, which is a container tag for the other tags
  • MTBlogSharesUserStockName
  • MTBlogSharesUserStockNumber
  • MTBlogSharesUserStockLink
• The plugin does not currently extract all the information that it possibly could, so if you have a specific request, please let me know and I'll incorporate it into a future version.

Update: (2003-05-06 16:11)

• I added another tag: MTBlogSharesUserStockSiteLink. It's just like MTBlogSharesUserStockLink, except that it returns a link to the actual site (which has been requested / hacked in a number of places already today). Enjoy! :)

Update: (2003-05-09 21:50)

• Updated to account for changes at the site. MTBlogSharesAvailable and MTBlogSharesTotalBonds should work now.

Update: (2003-05-15 10:39)

• For anyone who downloaded the plugin over the last few days, you may want to download it again. Thanks to me being a tad absent-minded lately, you either got a slightly older version if you downloaded it a couple days ago, or you got a broken version if you downloaded it yesterday. The version available now is working and has been verified by myself. I sincerely apologize for any problems I may have caused.
• In other news, the reason that recent copy was broken was because of a new feature I am implementing: MTBlogSharesOwnerSiteLink. For anyone that owns stock in your site, it will return the URL of their home page, if they have one listed in their Blogshares account.

Update: (2003-06-04 00:10)

• Seyed changed the site again. Amazingly enough, the URLs it uses haven't changed.
• MTBlogSharesTotalReal and MTBlogSharesTotalProjected are now considered deprecated. MTBlogSharesWorth replaces them.
• ( drum roll, please ) I have added three important new tags:
  • MTBlogSharesOwnerIfSite: if the stock owner has a site
  • MTBlogSharesOwnerSiteName: name of the stock owner's site
  • MTBlogSharesOwnerSiteLink: url of the stock owner's site
• These three new tags make use of MT::PluginData to cache home page data, so that is now considered a requirement for the plugin.

Update: (2003-06-06 13:54)

• Fixed a bug that occured when the blog's outgoing link value was less than $100. Thanks to Ryan for letting me know.

First, grab copies of the MTMacros and Entry plugins, and install them on your site.

Next, create the following macro:

<MTMacroDefine name="entry_link" ctag="entry_link">
<a href="
<MTEntry id="[MTMacroAttr name='id']"><MTEntryPermalink></MTEntry>">
<MTMacroContent></a>
</MTMacroDefine>

When setup to be included in your entries, this macro will allow you to use the created <entry_link> tag to link to another entry on your site. If you change the structure of your site, the entry only needs to be rebuilt and the links will point to the new archive location.

You can use it in your entries like so:

<entry_link id="125">This</entry_link> is a link to the entry with the id of 125.

As with other plugins , I've been meaning to write and release this one for quite some time, and I've only now actually done it. So, here is one of the most useful text parsing functions in Perl, wrapped in a Movable Type plugin: MTSplitLoop.

For those unfamiliar with the split function in Perl, here is the quick description taken from the split documentation page at Perldoc.com

Splits a string into a list of strings and returns that list.

In other words, given a string "A,B,C,D,E,F" and the pattern "," to split based on, split returns "A", "B", "C", "D", "E", and "F" so you can process each portion of that string by itself.

Download one of the following files, unpack it, and place splitloop.pl in your plugins/ directory.

• splitloop.tar.gz
• splitloop.zip

The following tags are available:

• MTSplitLoop: the main container tag that loops through each value in the list returned from the split function. It takes two arguments:
  • value: the string to be split. Can be in embeded MT Tag form (e.g. '[MTTag attr="something"]')
  • glue: the string or regular expression to split on. To split by regular expression, just format glue with slashes ('/') at the beginning and end (e.g. '/\d+/'). Defaults to ','.
• MTSplitLoopValue: the current value

Usage Example (with Brad's Key Values plugin):

<MTIfKeyExists key="files">
<p>File List</p>
<ul>
<MTSplitLoop value="[MTKeyValue key='files']">
<li><MTSplitLoopValue></li>
</MTSplitLoop>
</ul>
</MTIfKeyExists>

Another plugin I wrote while testing MTMoreLikeThisFromOthers . As before, I figured people could get some use out of this.

Here is an example of its use:

<MTEntry id="118">
<$MTEntryTitle$><br />
<$MTEntryBody$>
</MTEntry>

Download entry.tar.gz or entry.zip, unpack it, and place entry.pl in your plugins directory.

MTEntry

• Container tag for one specified entry
• Arguments:
  • id: the entry id to use ( required )

ChangeLog:

• Version 0.25: Now supports embeded MT Tags in the [MTTag attr="something"] format for the id argument
• Version 0.15: Fixed to work with MTEntryDate and MTEntryIf tags
• Version 0.12: Fixed to work with DB sites as well
• Version 0.1: First version

With the public release of the Technorati API today, I figured I would take a few minutes and start wrapping a plugin around it. Here's what I've got so far.

Download one of these files, unpack it, and place technorati.pl in your plugins/ directory.

• technorati.tar.gz
• technorati.zip

The following tags are available:

• MTTechnoratiCosmos: container tag for the Link Cosmos that Technorati generates.
• MTTechnoratiCosmosName: name of the weblog from which the link was generated.
• MTTechnoratiCosmosUrl: url of the weblog.
• MTTechnoratiCosmosRssUrl: url of the rss feed of the weblog.
• MTTechnoratiCosmosExcerpt: excerpt containing the link.

Usage Example:

<MTTechnoratiCosmos>
<a href="<MTTechnoratiCosmosUrl>"><MTTechnoratiCosmosName></a>:
<MTTechnoratiCosmosExcerpt><br />
</MTTechnoratiCosmos>

Minor (but Important) Update:

• You will be required to get your own API key from Technorati . You should be able to do so just by signing up (no cost to you). I have been unable to myself, but I imagine that is mostly due to user error. :) (Nevermind, I found it)
• When you get it, place the key on line 22 of the plugin file, between the single quotation marks.

My deepest apologies to all of my shareholders. It would seem that the Blogshares bot did not see the link from Blogshares to me this last time around, so when my blog was last re-indexed, its valuation went down nearly $10k, which caused the P/E to skyrocket, which caused the stock value to tank.

I assue you all that I am working to fix the situation. Hopefully the revenue stream from Blogshares will be restored in the near future. And in the long term, there should be a Plugin Manager release in the coming month, which promises to bring in many, many new links.

Hang in there. I assure you that it will be worth it.

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.

Today is the big day. BlogShares went live. I finally got a chance to get online and start playing again (and I've already make a few $K).

Hopefully I'll find the time tonight to update the MTBlogShares Plugin to go along with the site launch. Probably something with all the RSS feeds Seyed is providing us with.

I've been reminded and reminded over the last couple weeks that I have not yet released my MovableType email script. So, here is the first part.

Requirements:

• MIME::Parser
• MIME::Entity
• MIME::Head

Download:

• mt-email.tar.gz
• mt-email.zip

Installation:

• Unpack the archive
• Edit mt-email.pl: change the address on line 70 to the email address where you woud like your blog to receive mail
• Place mt-email.pl in your base MT directory
• Create an email forwarder/alias that redirects to the script (e.g. on my CPanel site, I created an Email Forwarder, blog@mt.rayners.org, that forwards mail to "|/home/rayners/www/mt/mt-email.pl")

How It Works:

• Takes the Subject of the email and searches for an entry on your site with that title (exact, case-sensitive match at the moment)
• Uses the mail headers to generate the comment author, email, and URL (for URL, it currently uses a non-standard header X-URL)
• Posts the contents of the email as the comment

Future Plans:

• Email => Entry
• Various forms of authentication (PGP/GPG signatures, Password, other?)

Update (2003-3-31 14:27)

• Added Email => Entry

  To use, send an email to the address you chose, with the subject in the following form

  New Entry: Entry Title

  And add some combination of the following headers to the email you are sending

  X-MT-Pass: password X-MT-Blog-Id: blog_id X-MT-Blog-Name: blog name X-MT-Category: Primary Category|Secondary Category|Other Secondary Category|...

  X-MT-Pass must be there, as well as either X-MT-Blog-Id or X-MT-Blog-Name. Everything else is optional.

  I would like to stress right now that this is not secure. You are sending your MT password in cleartext over email. Admittedly, you are effectively doing the same thing right now when you login to MT via the web. Most likely, this won't be an issue, but I want to be sure everyone is aware of it. I am currently working on adding in digital signatures (via GnuPG/PGP) to the email to verify identities instead of passwords.

In a little email conversation with Ben earlier today, I was inspired to write another plugin: CategoryHeaderFooter.

CategoryHeaderFooter provides tags that will return header/footer text depending on the current entry's category (or just upon the current entry if within MTCategories).

Download:

• categoryheaderfooter.tar.gz
• categoryheaderfooter.zip

Install:

• Unpack archive
• Place categoryheaderfooter.pl in your plugins/ directory

Usage:

• To set Headers/Footers:
  • Create a template using the following tags (the DEFAULT category is for entries with no category):

<MTCategorySetHeaderFooter
  category="Example Category" 
  header="<h2>Example Category Header</h2>" 
  footer="Free to use, publish, and reproduce">
<MTCategorySetHeaderFooter
  category="DEFAULT" 
  footer="Wahoo!">

• • Build the template
  • You're done (the headers and footers are stored in the MT datastore, so they don't need to be re-set with each rebuild of the other templates)
• To access the Headers/Footers:
  • MTCategoryHeader will return the header for the current category
  • MTCategoryFooter will return the footer for the current category
  • The current category will be taken from the current category if within MTCategories, or if that is not the case, the tags will take the primary category from the current entry
• Example:

<MTEntries lastn="15">
<MTEntryTitle>
<MTCategoryHeader>
<MTEntryBody>
<MTCategoryFooter>
</MTEntries>

Big Update: (to v 0.2)

• Removed MTCategorySetHeaderFooter in favor of new container tags MTCategorySetHeader and MTCategorySetFooter, which are able to re-set data in the database. They both take one argument: category which must be defined.
• Changed 'DEFAULT' to 'NONE' (no category)
• 'DEFAULT' is now for categories (including NONE) without header/footer currently set
• Header and Footer may now contain any and all MT Template Tags, e.g.:

<MTCategorySetHeader category="DEFAULT">
<MTEntries lastn="5">
Entry Title: <$MTEntryTitle$>
</MTEntries>
</MTCategorySetHeader>

It's official. Kristine has made the announcement. MT-Plugins.org Bug Tracker has gone on-line and is populated with all the plugins from the Plugin Directory.

From now on, I would highly appreciate if all bug reports and feature requests for my plugins be posted on that site. It would just help me keep things organized to better serve you. :)

Happy bug reporting!

It's been a while since I wrote just a plain plugin, and this doesn't really qualify as one. But it's close. I was inspired by a thread in the MT Support Forums today, and figured it was a good excuse to play with some of the new features in MT 2.6.

This is still a very preliminary version. I am far from finished. But it works, and there's enough code there for people to play around with in their blogs, so I figured I would release what I've got so far and keep working on it.

First, the new tags: MTVoteNumber, MTVoteAverage, and MTTotalValue. MTVoteNumber gives you the number of votes submitted. MTVoteAverage gives you the average vote value. MTTotalValue gives you the total value of all the votes.

Now, to cast a vote, use mt-vote.cgi. You'll have to setup a form or a link to a URL using the following fields: __mode, entry_id, and value. Set __mode to vote to cast the vote. The entry_id field contains the entry id on which to cast the vote, at value's value. For example, to cast a vote of 7 on entry 157, use the following URL:

http://www.yourdomain.com/mt-path/mt-vote.cgi
?__mode=vote
&entry_id=157
&value=7

So, to use this plugin, download either vote.tar.gz or vote.zip, unpack it, and place mt-vote.cgi in your base MT directory, Vote.pm in the lib/MT/App/ directory, and votes.pl in the plugins/ directory.

Planned for future versions:

• Threshold Actions (see thread linked above)
• Spiffy configuration interface
• Whatever else I come up with or other people suggest/request

Update (2003-03-06 16:13):

• Added a new container tag, MTVotes, that contains entries sorted by highest average vote. You can use any of the standard MTEntries tags within it, including the MTVote tags. It takes two arguments: lastn which defaults to 1 and current_blog_only which when set to 1 (it defaults to 0) will limit the entries returned to only those in the current blog.
• Added an argument to MTVoteAverage: places determines the number of decimal places to allow in the average, defaults to 0.

While I've been developing MTVote, I have received a few requests to help in the writing of HTML forms. Initially I was just going to incorporate something into MTVote, but then I decided that what I wrote was deserving of it's own entire plugin. So, I present to you: MTForm.

At the moment, it's only provides two tags: MTForm and MTFormSubmit. MTForm is a container tag that takes a required argument script that is the script to send the form data to, and an option argument path which defaults to the CGIPath in mt.cfg. MTFormSubmit produces a submit button for the form and takes one optional argument text that defaults to "Submit".

Here's a quick little example of how to use it:

I realize it doesn't do much yet, but in the spirit of Open Source software's motto "Release Early, Release Often," I am doing just that. Feel free to let me know what you'd like MTForm to do. I appreciate any and all suggestions.

Update: Download the tar.gz or zip archive.

Alex threw together a script to allow you to post to your blog via a signed email.

After playing around some with the CPanel for my site, I discovered something wonderful. CPanel can forward to pipes (i.e. CPanel can send emails to a program/script). So I am going to take Alex's idea, switch the paradigm to use piped in emails, and add comments to the mix as well.

Stay tuned for more information as it arrives. :)

Minor Update: Seems Alex's code already uses piped-in emails. My glance at the code was a little quicker than it should have been. Either way, I'm still reworking it. :)

Major Update: Okay, I've got it all working. GPG Keys, new entries, and new comments all work through email now. I'll package it up when I get home from class later this evening.

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

First of all, I've been promising for a couple days now to link to my friend Rob's blog, running MT, of course. He works (though a contract or three) as tech support for Apple, so hopefully he'll starting putting up some of the good stories he's been telling me. :)

I've also started to put together a site for my gaming group: The Plot Hooks. It's still in the very early stages (read: not exactly any content as of yet), but we're working on it. I've also got one up for the game we're currently playing, and some gaming forums and what will eventually be a miniatures/gaming gallery.

Enjoy!

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 was going to sit down and write up a little bit of documentation for remote post and ComeBack, but I was pretty busy this weekend and Ben beat me to it.

Now, let me give you a bit more of a technical description of those two:

ComeBack
A ComeBack ping consists of the following fields at the moment:

• name: name of the person writing the comment


• email: email of the person writing the comment


• url: url of the person writing the comment


• comment: the comment itself


• agent: the system or blog through which the comment was posted

remote post
A remote post ping consists of the following fields at the moment:

• title: the title of the original entry


• url: the url of the original entry


• excerpt: the full text of the original entry (field name is excerpt to be compatible with Trackback)


• blog_name: the name of the blog containing the origina entry


• category: the name of the category to which the remote post entry should be posted


• cb_url: the ComeBack url for the entry, should any comments be posted (not implemented yet)

A new version of remote post has arrived. In addition to everything included in Release 1, this version also introduces the following:

• Getting a list of available categories
• Posting to specific categories
• Entries placed via remote post now reflect the default blog settings (i.e. Allow Pings, Convert Line Breaks, and Allow Comments)
• Bundles in the script to send remote post pings

Download either remote post-2.tar.gz or remote post-2.zip, unpack it, and place the files as follows:

• ConfigMgr.pm: in the lib/MT/ directory
• remotepost.pm and remotepostWww.pm: in the lib/MT/App/ directory
• mt-pi.cgi and mt-www-pi.cgi: in the base MT directory

You will also need the XML::RSS perl module now. If you don't have that installed, you should be able to just download RSS.pm and place it in your extlib/XML/ directory.

Sending a remote post ping is now a two step process:

1. Bring up mt-www-pi.cgi in your browser and enter the remote post Ping URL
2. The script will then connect to the URL and get a list of categories available on that blog, and present them to you along with a list of entries to pick from and an option to include the ComeBack URL

And just to make sure I have made it explictly clear (which apparently I haven't, and I apologize for that), ComeBack is not fully implemented yet. ComeBack pings can be received by MT, but at the moment, they cannot be sent. I am working on that. Placing a ComeBack Ping URL in the URLs to Ping box in the New/Edit Entry screen will not work for ComeBacks. The ComeBack implementation is currently very different than Trackback, so pinging that way will fail. The send-cb script that I mentioned with the initial release of ComeBack was just meant as an example. It is not for use within MT.

I'll get them working together soon. I promise. :)

Here you can grab a little script to send true remote post r1 pings. Download either send-pi.tar.gz or send-pi.zip.

In the archive, you'll find two files:

• mt-www-pi.cgi: place in your base MT directory


• remotepostWww.pm: place in your lib/MT/App/ directory

To use this script, browse on over to your mt cgi path, and bring up mt-www-pi.cgi (or mt-www-pi.pl if you have to rename it). You'll be presented with a (complete) list of entries in your MT install, along with a box for the remote post ping url, and a check box for including the ComeBack URL in the remote post ping. Select your entry, enter the ping url, decide whether or not to include the ComeBack url, and hit the send button. The resulting page will let you know if everything went through okay or not.

For the moment, remote post is storing the ComeBack URL for the original entry in the Keywords field of the entry in the remote post blog. Adding a seperate field to store the ComeBack URL will require a change to a number of MT files, and to the database as well. I can work that up if anybody is interested, but I figure it'd be best to officially integrate remote post and ComeBack into MT instead.

Next: a patched version of the MT::App::Comments module that will send ComeBack pings when appropriate.

Update: This has been superseded by remote post - Release 2.

Here it is, folks! You can see remote post in action in my remote post Test Blog, or now in use at the official LazyWeb site.

Download the archive, either remote post.tar.gz or remote post.zip.

In the archive, you'll find three files:

• mt-pi.cgi: place in your base MT directory
• remotepost.pm: place in lib/MT/App/ directory
• ConfigMgr.pm: place in lib/MT/ directory

ConfigMgr.pm is a patched version of the MT 2.51 version. It contains all of the new configuration directives for remotepost and ComeBack.

To enable remote post on your installation, put the following lines in your mt.cfg file (only use remotepostScript if you have to change the name of mt-pi.cgi):

remotepostBlog blog_id
remotepostAuthor author_id
remotepostScript mt-pi.pl

Those are the blog and author remote post uses to determine where to place the new entry. They default to 0, so you should define them. :)

I should (hopefully) get remote post and ComeBack working together nicely by the end of the week. Until then, I'd suggest you setup the blog for remote post to not allow any comments on entries by default.

How To Send A remote post Ping

• Find the remote post URL for the blog (e.g http://blog.mediacooperative.com/mt-pi.cgi for LazyWeb)
• Write your entry
• Copy and paste the entire entry into the Excerpt field
• Save and ping away

Future plans for remote post:

• Integration with ComeBack
• Quickie web interface (instead of using Excerpt kludge)
• Multiple remote post destinations in one MT installation (i.e. like how Trackback works now)
• Category support:
  • remote post Category auto-discovery/advertisement
  • Multiple or Single category per remote post destination
• New MT Idea: ComeTrackBack? (Trackback ping received on a remote post posted entry)

Well, now that I have basic versions of ComeBack and remote post working, I had a few thoughts about Inter-Blog Pings in general.

There seem to me to be a few different types of pings now:

1. Update pings
2. Trackback pings
3. Pingback pings
4. ComeBack pings
5. remote post pings

Doesn't it seem time to provide a common API for all these? Or at least unify all the code for them in a single Perl module. Trackback code is all over the MT core at the moment (at least as far as I've seen). In MT.pm and MT/App/Trackback.pm mostly.

It would make more sense to me to have something like the following: lib/MT/Ping.pm lib/MT/Ping/Update.pm lib/MT/Ping/Trackback.pm lib/MT/Ping/Pingback.pm lib/MT/Ping/ComeBack.pm lib/MT/Ping/remotepost.pm

That way all of the inter-blog communication code could be encapsulated in this Ping.pm module, allowing the easy creation and modification of pings. All the remotepost.pm module would have to worry about is posting the actual entry to the blog. It would not have to go through all of the steps needed to parse out the parameters from the HTTP Query string. And along those lines, this would also facilitate moving to another form of inter-blog communication. If you wanted to go XML or the like, just make the changes in Ping.pm and everything is wondeful in the land of pings again. Nothing to change in any of the other files.

Well. those are my thoughts for now at least.

This post is being posted to my remote post Blog. Go ahead and give it a try yourself. At the moment, it's just a cheap version of Trackback. Stuff your entry in the excerpt field, and put http://mt.rayners.org/mt-pi.cgi in the URLs to Ping box. After pinging my site, it should appear as an entry in my remote post Blog. Tomorrow I'll release a cleaned up version of my remote post code and I'll start integrating it with ComeBack.

Enjoy!

Let's see if this thing actually works. :)

Update:

IT WORKS!!

remote post should function almost exactly like Trackback does right now, with one or two major exceptions:

1. A remote post ping would send the entry in its entirety, not just the excerpt


2. A remote post ping may have an additional field to transmit: a ComeBack link

The need for a ComeBack link depends on whether or not I decide to go ahead and implement ComeBack auto-discovery, which should be easy enough to do once I get off my lazy butt. Now that I think about it, I should go ahead and do this anyway. I imagine RSS Aggregators would probably need it, unless the ComeBack link was included in the RSS to begin with.

Essentially then, a remote post ping is a Trackback ping with a complete entry. That's the only change.

Okay, here is the packaged up version of ComeBack for Movable Type.

1. Download cb-mt.tar.gz or cb-mt.zip
2. Unpack the archive and place:
   • ComeBack.pm in your lib/MT/App/ directory
   • ConfigMgr.pm in your lib/MT/ directory
   • cb_url.pl in your plugins/ directory
   • mt-cb.cgi in your base MT directory
3. Add the following line to your mt.cfg file if you have to rename mt-cb.cgi to something else (e.g mt-cb.pl): ComeBackScript mt-cb.pl

The plugin part adds the following tags to MT: MTComeBackScript and MTEntryComeBackLink. You can use them just like their Trackback cousins.

I also implemented an example ComeBack pinging script. You can download send-cb.tar.gz or send-cb.zip. In there are two files, send-cb.pl and XML/ComeBack.pm (which is basically a hacked-up version of Tim's XML::TrackBack perl module.

Play around with them and see what happens.

Update: Fixed a couple bugs. Download the new archive.

Just for the heck of it, I wrote up a quickie implementation of ComeBack on this blog. If you see any comments in this entry from me, that's how they got here.

You can ComeBack ping this entry with the following url: http://mt.rayners.org/mt-cb.cgi/139

Give it a shot!

Well, we have TrackBack, Pingback, and RSS, so I just continued that line of thinking.

For example, you have a site like LazyWeb, which is intended to passively aggregate content via a somewhat sideways use of TrackBack. At the moment, the page contains a list of links and excerpts. However, I think it might actually be better served by having entire entries posted to the site, along with links back to the original entries. That way LazyWeb readers can be even lazier. There would be no need to actually click one more link to go and read the entry in its entirety. That is what I would like to call PostForward (I thought remotepost might be a better name, but that may have some problems. Maybe Stickee would work?).

The other side of this idea is what goes on when somebody leaves a comment. Say I go ahead and sent an entry to LazyWeb via PostForward (or remotepost, or Stickee, or whatever we call it). That entry appears in its complete form on the LazyWeb site. Why force people to browse over to my site just to leave a comment? They can do that if they want to read more of my content, but if they only wish to leave a comment that seems a little silly. This is where CommentBack (or maybe ComeBack? LOL) comes in. When somebody leaves a comment on the entry at LazyWeb, a CommentBack connection is made from the LazyWeb site to mine, containing all of the comment data (timestamp, author, email, site, and comment text). This comment can then be displayed in my site's list of comments for that entry, along with a link to the site from which it orginated.

Now that I think about it, this type of system would be perfect for News Aggregators. The content is aggregated for the user already. They could just leave a comment in the aggregator itself, which would then be forwarded on to the site hosting the entry, which could then be forwaded on to the originating site if that entry was posted there via PostForward, and so on.

Here's a thought I had today: Nested Blogs (aka Blogs within Blogs).

I am beginning to put together a website for my gaming group (it's in a temporary location until we decide on a domain name). I plan on having one main blog for the group, to which everyone will have access, and one blog for each game that we're playing, with access given to the guys that are playing it. I suppose I could create categories for each game, but they really deserve their own blog.

I think it would be a wonderful thing to have all of those game blogs be contained within the main blog. When created, they could inhert it configuration from the Main Blog, so if any changes were made to it, they would be reflected on the Game Blogs. I could authorize users to create a blog within the Main Blog, but not system-wide. The core template tags (MTEntries, MTComments, etc.) in the Main Blog would default to including content from all the blogs contained within the Main Blog. The idea there is that, even though I could use some combination of MTOtherBlog and MTWholeSystem/GlobalListings), it would be a really tedious operation to change all the templates whenever I add or remove a Game Blog.

I imagine there's many more benefits to doing this, but I haven't been able to think of any others just yet. ;)

I don't know where all these ideas are coming from, but they just keep coming and I need to get them down on paper (so to speak). Maybe it's all the medicine I'm taking for my cold.

As things are now, Movable Type plugins can only effect Template output by defining new Tempalte Tags and Global Filters. But what about other parts of MT? What if Kevin wanted to write a nice elegant way for users of his ExtraFields plugin/hack to create and edit their Extra Fields? What if Brad wanted to create a user-friendly interface for people write Macros for his MTMacros Plugin?

The answer: Interface Plugins.

Just like the way Template Tags work, programmers could be given an API with which they could add or modify any part of the MT Interface that they so desired. These plugins (heck, why not all plugins? More fun ideas for my Plugin Manager) could be enabled on a Blog by Blog basis, and in the case of Entry Interface Plugins, on a Category by Category basis.

If you have a PhotoBlog, you could create a new New/Edit Entry Interface with the visible names of the fields renamed to something more appropriate for your blog (that's assuming you are using those fields in a way in which they were not originally intended, e.g. Exceprt is actually used to store a Thumbnail URL). You could also change the Preview Entry Interface to reflect those new field uses.

Or maybe you generate a number of similar looking entries (like all my plugins) and want to create a more 'Fill In The Blanks' form-style New/Edit Entry Interface. Right now, I do that with Brad's MTMacros Plugin, but sometimes I go more than a few days between plugin releases and I can't remember the exact structure of the Macros I created (okay, so I can be a little lazy, sue me). I would love to be able to construct a New/Edit Entry Interface that has basic text boxes for plugin name, plugin description, plugin example, plugin tag, and so on.

I realize this is a massive change from the way MT works right now. But I think it would be a great feature to have. And being the glutton for punishment that I can be, I imagine it would be a lot of fun to implement as well.

Any thoughts?

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.

MTOtherBlog is a plugin that allows you to include Templated content from other blogs in your own, as long as they are all on the same installation of MT.

Here's an exampe of its use:

<MTOtherBlog blog_id="3">
<h2><$MTBlogName$></h2>
<MTEntries lastn="2">
<$MTEntryTitle$>: <br />
<$MTEntryExcerpt$><br />
<br />
</MTEntries>
</MTOtherBlog>

Download otherblog.tar.gz or otherblog.zip, unpack it, and place otherblog.pl in your plugins directory

<MTOtherBlog>

• Container tag that switches the context of the template to another blog on the MT installation (i.e. all the Template Tags will act as if they are in the specified blog instead of yours)
• Arguments (one must be present)
  • blog_id: the id of the blog you want to include
  • blog_name: the name of the blog you want to include
  • exclude_blog_id: the id of the blog to exclude (all the rest will be included)
  • exclude_blog_name: the name of the blog to exclude (all the rest will be included)
  • In all four arguments, you can put in a list of blogs, seperated by a comma (e.g. <MTOtherBlog blog_id="2,3,4">)
  • exclude_current: when set, it will include all blogs except the current one

ChangeLog:

Version 0.25: Added exclude_blog_id, exclude_blog_name, and exclude_current

Version 0.18.1: Added some error checking output to help find a bug

Version 0.18: Added ability to use multiple other blogs

Version 0.1: First version

Based on a request in the MT support forums, I coded up another plugin.

Update: D'oh! I managed to leave in some debug code, so if you see a strange and unexpected bit of text output from the plugin, that's why. I took it out and created new archives.

<h2>Latest Entries</h2>
<MTWholeSystemEntries lastn="5">
<a href="<$MTEntryLink$>"><$MTEntryTitle$></a> on
<a href="<$MTBlogURL$>"><$MTBlogName$></a><br />
</MTWholeSystemEntries>

Download wholesystem.tar.gz or wholesystem.zip , unpack it, and place wholesystem.pl in your plugins directory.

MTWholeSystemEntries

• Container tag for entries
• Changes local context to blog of current entry (like MTOtherBlog )
• It takes the following arguments:
  • lastn: the number of entries (defaults to 1)

ChangeLog

• Version 0.1: First version

Thanks to an entry on Ben's site, I am now aware of nntp//rss, a program that acts as a bridge between RSS feeds and a newsreader. I'm going to have to take that for a spin when I get home.

Though, according to the documentation, it listens on port 119, which is currently occupied by inetd and Leafnode on my main box. Maybe I'll have to see if I can change the port, assuming of course that I can specify the server port in slrn.

This could certainly solve the problem I was having before.

MTRandomEntries is a plugin that, like MTRandomComment , pulls out a random entry from the current blog.

Usage Example:

<MTRandomEntries category="Gaming" lastn="5">
<a href="<$MTEntryLink$>"><$MTEntryTitle$></a>:<br />
<$MTEntryExcerpt$><br />
</MTRandomEntries>

Download randomentries.tar.gz or randomentries.zip , unpack it, and place randomentries.pl in your plugins directory.

MTRandomEntries

• Container tag for the random entries that acts like MTEntries
• If used within MTCategories , the random entries are chosen from current category.
• If used within MTEntries , MTEntry , an Individual Archive, etc. or anything that contains an entry, the random entries are chosen from the categories of the current entry, OR-ed together.
• It takes the following arguments:
  • category: Restrict the list of entries from which the random entries are chosen to those in specific categories. You can either supply a specific category, or use AND or OR like in MTEntries
  • lastn: Generate n random entries, defaults to 1

ChangeLog

• Version 0.5: Added support for current entry categories
• Version 0.45: Added support for AND and OR in category argument
• Version 0.3: Added support for MTCategories
• Version 0.2: Fixed lastn > number of entries bug
• Version 0.17: Fixed MT Date tag bug
• Version 0.15: Fixed bleeding
• Version 0.1: First version

The whole More Like This From Others thing really intrigued me, so I thought I'd write a little plugin for it to toss into my blog and see what comes up. So here it is.

Here's an example of how you can use it:

<MTPings>
<a name="<$MTPingID$>"></a>
<span class="trackback-post">
<a href="<$MTPingURL$>" target="new"><$MTPingTitle$></a><br />
<b>Excerpt:</b> <$MTPingExcerpt$><br />
<b>Weblog:</b> <$MTPingBlogName$><br />
<b>Tracked:</b> <$MTPingDate$><br />
<b>More Like This:</b><br />
<ul>
<MTMoreLikeThisFromOthers>
<li><a href="<$MTMLTFOLink$>" target="new">
<$MTMLTFOTitle$></a>: <br />
<$MTMLTFODescription$></li>
</MTMoreLikeThisFromOthers>
</span>
</div>
</MTPings>

Download morelikethis.tar.gz or morelikethis.zip , unpack it, and put morelikethis.pl in your plugins directory. In addition, you will also have to get Ben's MLTFO perl module from the link at the beginning of this entry. Just download the archive, unpack it, and place MLTFO.pm in your extlib directory. You may also need to install the XML::RSS module for Perl. All I ended up having to do was place RSS.pm in the extlib/XML directory.

MTMoreLikeThisFromOthers

• Container tag that encapsulates Ben's MLTFO module.
• When used within MTPings, finds similar entries in the blog from which the trackback ping was received.
• When used within MTPingedURLs finds similar entries in the blog to which the ping was sent.

MTMLTFOLink

• The URL for the entry that was found.

MTMLTFOTitle

• The Title for the entry that was found.

MTMLTFODescription

• The Description for the entry that was found.

ChangeLog

• Version 0.29: Fixed interation with MTPingedURLs
• Version 0.25: Added support for MTPings and MTPingedURLs
• Version 0.1: First version

Since I've got so many plugins out there, I figured it'd be best to have some sort of centralized place for feature/enhancement requests and bug reports, so I setup some forums for just that purpose.

Take a look, and enjoy! :)

*UPDATE: I have just been informed that the Related Entries plugin already does this; it's just not documented at the site. You can use it like this:

<MTRelatedEntries field="keywords">
        <MTEntries lastn="3"> 
	        <p><a href="<MTEntryLink>"><MTEntryTitle></a> -
<i><$MTEntryDate format="%b %d, %Y"$></i></p>
        </MTEntries> 
</MTRelatedEntries>

Prompted by a thread on the MT Support Forums , I wrote yet another plugin.

Here's an example of how you can use it:

<MTEntries lastn="6">
<$MTEntryTitle$>
<ul>
    <MTRelatedEntriesByKeyword>
    <MTEntries lastn="5">
    <li><$MTEntryTitle$></li>
    </MTEntries>
    </MTRelatedEntriesByKeyword>
</ul>
</MTEntries>

Download relatedkeyword.tar.gz or relatedkeyword.zip, unpack it, and place relatedkeyword.pl in your plugins directory.

MTRelatedEntriesByKeyword

• Acts exactly like the MTRelatedEntries plugin
• Keyword note: this plugin assumes all keywords are stored as single "words" seperated by whitespace (e.q. 'plugins', 'computers', and 'movable_type' are keywords it sees, whereas 'movable type' is seen as 'movable' and 'type')

ChangeLog

• Version 0.1: First version

Well, I've looked. So far, Straw, Flock, K.R.S.S. are the best (read: only) thing I have found. The list of blogs I read on a daily basis is starting to grow, so it's about time I start using an aggregator of sorts. I'll have to start playing with them when I get a chance. KRSS isn't impressing me all that much so far.

Can anybody point me in the right direction? Maybe I'll just get off my ass and write one myself. Perhaps this will be the project that takes up a good bit of my time.

Well, for anyone who reads this site or the MT boards, you may have noticed I've been churning out plugins like crazy. Since I'm sitting here at home thanks to the snow, I figured I might as well solicit some new ideas.

So, go ahead and leave a comment with a plugin idea you've had, one you'd like to see, whatever comes to mind. What could you use?

I saw some php code for this, so I thought I'd take it one step further and make this into a plugin.

Here's an example of how you can use it:

<MTEntries lastn="15">
<MTDateHeader>
<br />
<MTEntryRelativeDate format="%x"><br />
</MTDateHeader>

<$MTEntryTitle$><br />
</MTEntries>
</codesnip>

<MTEntryRelativeDate>, <MTCommentRelativeDate>, <MTCommentPreviewRelativeDate>, <MTArchiveRelativeDate>, <MTCalendarRelativeDate>, and <MTPingRelativeDate>

• They all act exactly as their non-relative versions do, taking the same arguments (format and language)
• They will return "Today" or "Yesterday" when appropriate for the blog's timezone (i.e. any time after midnight this morning is Today, anytime between then and midnight the previous night is Yesterday)
• Arguments:
  • include_date: include the date in the Today and Yesterday outputs (e.g <MTRelativeDate format="%x" include_date="1">)
  • glue: text to put between Today/Yesterday and the date, defaults to ", "

ChangeLog:

Version 0.15: Added include_date and glue

Version 0.1: First version

MTSearches in a container tag that will go through all the of the searches that have been made on your site.

Here's how I use it:

Recent Searches:<br />
<MTSearches lastn="8" unique="1">
<a href='<$MTCGIPath$><$MTSearchScript$>?search=<MTSearchValue>'>
<MTSearchValue></a><br />
</MTSearches>
<br />
Top Searches:<br />
<MTSearches lastn="10" rank="1">
<MTSearchRank>. <a href='<$MTCGIPath$><$MTSearchScript$>?search=<MTSearchValue>'>
<MTSearchValue></a> 
(<MTSearchTotal>)<br />
</MTSearches>

Download recentsearch.tar.gz or recentsearch.zip , unpack it, and place recentsearch.pl in your plugins directory.

MTSearches

• container tag for the list of searches that are pulled from the log
• arguments
  • days: to include searches from only the last n days (e.g. <MTSearches days="7">)
  • lastn: to include n searches in the list (e.g. <MTSearches lastn="5">), if no other arguments are giving, these are just the last n searches
  • unique: to include only the latest instance of a particular search (e.g. <MTSearches unique="1">)
  • rank: orders the searches by rank, the most common being the first (e.g. <MTSearches rank="1">), implies unique

MTSearchValue

• the value of the current search

MTSearchDate

• the date of the current search
• takes one argument, format, used just like MTDate

MTSearchIP

• the IP from which the search was requested

MTSearchTotal

• the number of times this specific search has been made

MTSearchRank

• the rank of the search overall, 1 being the most common

ChangeLog:

• Version 0.61: Bugfix: Now it works in December
• Version 0.60: Added days to MTSearches
• Version 0.52: Added MTSearchTotal, MTSearchRank, and rank to MTSearches
• Version 0.45: Added MTSearchIP and unique to MTSearches
• Version 0.35: Fixed month+1 bug
• Version 0.31: MTSearchDate now adjusts itself to the local timezone of the blog
• Version 0.3: Added MTSearchDate
• Version 0.2: Added lastn to MTSearches
• Version 0.1: First version!

Because of the way I wanted to use MT for one of my blogs, I thought Author-based archiving could be extremely useful. Instead, initially, I had to do a little work-around using Categories. But, today I sat down and implemented Author Archives in MT.

You can see this code in action on the campaign journal blog I setup for a game I was in.

The following is the diff I generated from my new code, which I will make available for anyone who is interested in testing:

I've got a couple blogs on my site, and I list them all on my main page. I wanted to display the number of authors for each blog, mostly because one of them is for a game that a bunch of friends and I are playing. So MTBlogAuthorCount was born.

Download it here.

<MTBlogAuthorCount>

• when used in the <MTBlog> context, it will display the number of authors in the blog
• when used alone, it will dispaly the number of authors in the current blog

Changelog

Version 0.11: Fixed bug that occured during comment submission
Version 0.1: First version

Because of how I wanted to use MTMacro (so far at least), I decided to add a fouth type of macro (in addition to string, pattern, and tag / ctag): word.

Basically, word is just a specialized form of pattern, but formatted like string. All my additional code does is put the word into the following pattern: m/\b$word\b/

Here is the diff I generated for my code changes:

For those of you who are either new to the site, or are just totally blind, you may have noticed a change in the layout. I installed the new version (2.5) of MovableType.

The new default templates have taken into account some suggestions from 30 Days to a More Accessible Web site, pretty much all of which I happen to agree with. So I figured I'd just bite the bullet and start from scratch. I'll be adding back in my Game Quote Submission System in a couple days, as well as tweaking some of the templates back to where I want them.

Hopefully, when all is said and done, I'll actually have me a nice litle website. Who knows? :)

Well, I took the plunge tonight and hacked away at the MT code. I wanted to implement a way to use the blog I've already got to manage the web links on my main page.

First I tweaked the <MTEntries> code as follows (in lib/MT/Template/Context.pm):

Basically, what that does, in addition to being about to use AND and OR to pick the categories for MTEntries, is allow you to limit the categories with NOT, followed by one or more categories to exclude.

For example: <MTEntries category="NOT Links Web Local">

Then I added another MTEntries section to my Index Template for just the Links category.

It's certainly not perfect. This is only my first pass at things, and it is late at night. I'll have to take another look at it later this week when work lightens up a little bit.

The next thing I would like to do is enable something like a nested MTCategories within a MTEntries section. I'd like to be able to get a list of the categories within that group of entries so I could do some kind of heirarchical list of links.

UPDATE: You can download the complete Context.pm file here.

UPDATE AGAIN: Just because I'm lazy, I'll just go ahead and quote myself from the post on the MovableType Support forum:

I hate to reply to myself, but I figured I should mention what I just found out.

Apparently (maybe this is general knowledge, but I was unaware of it), when you limit MTEntries with category, the default days (i.e. taken from the blog config) is tossed out, and any days argument is ignored. I had to use lastn to keep my entire blog (all but the Links category) from being printed out. Luckily, my blog is still relatively new, so there aren't many entries. :)

I've looked through the code and I see where and why all this is happening, but I don't have the time to change things at the moment. I'll probably tackle it tonight.

Well, it is done! I've tested it and it seems to be working without problem.

And here's how I did it:

I eventually came to the decision to use Movable Type's built-in comment system instead of taking the time to roll my own. I created what I'll call a shadow entry in the blog. Basically, it's an entry that will forever stay at Draft instead of moving to Publish.

After adding that to the database, I grabbed the entry_id out of the mt_entry table, and copied the Individual Archive Entry template into a new Index Template I called Submit Random Game Quote. I snipped out every template tag having to do with entries, and I was left with a title and an html form. I put the entry_id of the shadow entry into the form fields, and that was it. My submission page is complete.

And here is the code I used to pull out the Random Game Quotes:

$link = mysql_connect ("localhost", "username", "password");

mysql_select_db ("mt", $link);

$query = "SELECT comment_id
          FROM mt_comment
          WHERE comment_blog_id = 1
            AND comment_entry_id = 26";

$res = mysql_query ($query, $link) or die ("Invalid query: $query<br />". mysql_error ());

$total = 0;
while ($row = mysql_fetch_array ($res)) {
  $id[$total] = $row[0];
  $total++;
}

$quoteId = $id[rand (0, $total - 1)];

$query = "SELECT comment_text,  comment_author, comment_email
          FROM mt_comment
          WHERE comment_id = $quoteId";

$res = mysql_query ($query, $link) or die ("Invalid query: $query<br />".mysql_error ());
$row = mysql_fetch_array ($res);

$quote = str_replace ("\n", "<br />", $row[0]);

echo $quote."<br /><br />\n";
echo "<em>Submitted by:</em> <a href='mailto:".$row[2]."'>".$row[1]."</a><br />\n";

echo "<br />\n";
echo "<center><font size=-2><a href='/submitquote.php'>Submit a new Game Quote</a></font><br /></center>\n";