David Raynes

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)

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!

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.

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.

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