A friend of mine recently expressed their confusion over the GPL and how it all relates to the recent bruhaha happening in WordPress land. A quick search on Google will reveal a number of people attempting to answer the same question. Here is my own attempt to answer this question, paying special attention to how this may relate to WordPress themes and plugins.

In an effort to further everyone's understanding of the GPL, let me see if I can shed some light on what the GPL is and how it works.

1. The GPL governs ones rights to redistribute software using the GPL as a license.

2. The GPL gives me the right to take GPL code and redistribute it as is (provided that I also respect any related trademarks). For example, I can't take Firefox and redistribute it under the name "Firefox" since the name is a trademark owned by Mozilla and only they have the right to convey its name on software.

3. Believe it or not, the GPL also allows people to sell copies of GPL software. Most people don't understand this for one simple reason, "why buy the cow when I can get the milk for free." Selling GPL software just doesn't make sense in that regard. But it has been done very successfully. People used to sell Linux on CD - but the value of doing so was clear: at the time to download Linux could take days, so for many shelling out $29.95 for the 5 of so CDs was a huge convenience.

4. The GPL also says that you can take GPL software, and modify it and redistribute it as well. For example, Microsoft could take the OpenOffice suite, make tons of changes (under auspices of making it better) and then turn right around and sell it. --- There is a catch though, any change you make to GPL software AND also redistribute you must also make available under the same license. In other words, Microsoft would need to make any changes they made to Open Office freely available to others.

   Note: the key here is "redistribution." Because the GPL governs distribution only, it means that I could, as an individual, take OpenOffice, make changes of my own that are TOTALLY AWESOME (naturally) and, provided that I never give a copy of that software to a friend or anyone else, I would never have to share my modifications.

   Another Note: the above note is important because this is why it is reasonable and acceptable for someone to download a copy of WordPress, modify it, pay a consultant to modify it, add features to it, redesign it, etc, etc, etc. and never be compelled to share the mods they have made, or be compelled to open source anything else in their organization.

5. The GPL also says I can take a portion of code from a GPL program and include it in my own. For example, say I want to write a blogging platform in Perl. I have written most of the code myself, but I deem Movable Type's commenting system to be perfect. So I cut and paste large portions of it into my software. Under the GPL, this is equivalent to forming a derived work, and my new blogging platform is compelled to be GPL as well.

Now let's look at what makes the WordPress theme debate special:

• The GPL defines something called a "derivative work." When I take Firefox, edit the source, recompile and redistribute it, that forms an obvious derivative work. All derivative works are bound by the terms of the GPL.

• The GPL also defines a derivative work as a piece of software that runs in the same shared memory space as a GPL program. In layman's terms this means that if a piece of software, say a theme or plugin (even it is distributed separately from the another piece of GPL software), is designed to run in conjunction with GPL software, then the two of them, by virtue of sharing the same memory/process when they run form a derivative work, and thus, the theme/plugin is bound by the GPL.

Ok, why the debate?

Well, their is some ambiguity over what forms a derivative work. I believe this stems from the fact that most people don't understand technically the concept of "shared memory space." But I believe this FAQ answer from the FSF makes clear the intent of the licensor:

If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in?

If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed. (emphasis mine)

So, although the Free Software foundation states their belief that this forms a derivative work, their own language admits that it does not conclusively do so.

But Byrne, I still don't understand all this techno-mumbo-jumbo. Just tell me, why is there a debate?

Let's clarify one more thing that I have seen many people get confused about. The GPL is NOT law. It is just a contract between two parties. If those two parties have a dispute over the terms, or their interpretation of the contract, then it is up to a judge to resolve the dispute and assess damages.

What makes the GPL special with regards to contracts is that is a standardized one. Meaning tons of people have accepted and/or conveyed the license to others. So if a judge rendered a judgement that helped to resolve the ambiguity of what constitutes a derivative work, then just like that, we would have legal precedence to reinforce anyone else's claims contingent upon this definition.

Finally, let's suppose Matt does sue Chris Pearson, what could he actually get from Chris?

I do not personally think Matt can claim that he has suffered any damages (e.g. lost revenue) from Chris' distribution of a proprietary theme, so I don't think a law suit would result in any money changing hands. But Matt can ask a judge to compel him to comply with the license and force him, by way of a court order, to distribute his themes according to the terms of the GPL. That's it.

And that is my take on the GPL, especially with regards to themes. I have my opinion as to whether Chris should open source his themes, but at the end of the day it doesn't matter what I think because in my mind this amounts to nothing more than a contract dispute between Chris and Matt. So, have at it guys. Wait, let me get some popcorn.

Ok, now have at it.

Media Manager provides users and authors within Movable Type and Melody with the ability to search and insert media from a number of popular remote services like Amazon and YouTube. Using Media Manager one can open a dialog, enter a few search terms, select the book, DVD or video and optionally insert it into a blog post.

Once the media item has been selected it is automatically inserted into Movable Type or Melody's asset management system and can be view by going to "Manage Assets" under the Manage menu.

Installation

To install this plugin follow the instructions found here:

http://tinyurl.com/easy-plugin-install

Prerequisites

Keep in mind that before installing Media Manager you need to make sure you have:

• Movable Type 4.01 or greater.
• Digest::SHA perl module
• Cache::File perl module

Download

Download Media Manager from github.

Resources

For Media Manager

• Template Tag Documentation
• Frequently Asked Questions

Related

• Melody
• MovableType
• Media Manager Homepage
• Amazon Web Services
• Net::Amazon

Bug Reports

You can file bug reports here:

• Via the Web
• Via Email

Help and Donations

Media Manager represents a lot of work by one individual. While the author is happy to write this software, and support it completely free of charge, the author also appreciates and form of support you can provide. Please consult the following URL to learn more:

http://www.majordojo.com/projects/mediamanager.php

Copyright

(c) 2007-2008 Six Apart, Ltd. (c) 2009 Byrne Reese

License

Media Manager is licensed under the Artistic License.

This weekend I was pleasantly surprised by an email from Aaron Stone, the lead engineer of modperlite -- a project the two of us had started while we were both at Six Apart focused on addressing ways to dramatically improve performance for Movable Type. Aaron had done a lot of the initial groundwork for the project technically, but eventually got consumed by other projects in need of his expertise; a trend that did not stop when he moved on to Google.

I had in fact began recruiting for engineering talent to contract with to complete the project. But then this weekend, I got an email from Aaron out of the blue informing me that he finished the work on mod_perlite and tested it with Movable Type... and it worked!

This is a tremendous milestone for the project and puts us in a position for the first time to see if the original hypothesis for the project holds water: that we could make Perl applications as brain-numbingly easy to install as PHP-based ones, and that we could also help make all CGI faster and more memory efficient in the process.

• Learn more on the modperlite website.
• Download modperlite from github (official distributions to come soon).

People who know me, know that I love Movable Type. In fact I have devoted much of the last five years to the product and its community. Therefore it gives me great pride and much relief to be a part of the launch of Melody, a new community-driven content management and blogging platform based upon Movable Type.

I have written extensively about what motivated me and others to create this project so I won't bother recapitulating that here.

What is likely to get lost today in whatever attention this humble project is likely to attract is any mention of the people who have helped take this project this far. Without the dedication of these people over the past six years Movable Type would be a fundamentally different product than it is today, and Melody might never have happened. So I would like to carve out a little space to say thank you to the following contributors to Melody and my friends:

• Jay Allen - While I have been remiss in mentioning it here, Jay and I are now partners in what is becoming a very successful Movable Type (and now Melody) consulting business. For Melody Jay has been playing the role of lead developer by helping manage code merges with Movable Type, organizing our source code and writing all of our developer contribution guidelines.

• Jesse Gardner - I have worked with Jesse for years. It was a pleasure to work with him on the design of Movable Type [dot org] and an even greater privilege to work with him on what I think is a damn fine looking web site and the home for our new community: OpenMelody.org.

• Tim Appnel - Tim has been a dutiful project manager as well as our system administrator taking on the unglamorous and thankless task of setting up servers, managing ACLs, and all the other stuff that makes the bits and bytes flow as God intended.

• Dan Wolfgang - Dan built out our web site, and has been first in line to take stuff off of people's plates when they become too full. Never under-estimate the value of load balancing people. Seriously.

• Mark Stosberg - Mark's invaluable experience in serving on the boards of several non-profits has helped us greatly in our process of writing our own by-laws for the Open Melody Software Group. He is also our unofficial ambassador to the greater Perl community in CPAN, where he helps to maintain a number of modules.

• Su - I have never known Su to be one who likes the lime light, so I will simply say this: he has been a consistent and reliable voice of reason within our group, which is essential when dealing with so many people who are as passionate as we are.

• Arvind Satyanarayn - The famous Movable Type prodigy-kid and author of Custom Fields took a break from college girls and parties to help contribute much needed code and infrastructure that will undoubtedly become essential to the project. He also surprised us all by merging all of Movable Type 4.261 into the latest development branch of Melody - hoooo-aaaah!

Finally, I would like to thank Six Apart. There is no doubt that many people will want to spin this initiative by the community in a way that impugns the company and the many people who work there and whom I call a friend. There is no way around the simple and basic truth: without them, this project would not exist and without their support of the project, I doubt it could reach its fullest potential.

And after all is said and done, this is what Melody is all about: these people, our community, and the many people who will follow. Thank you!

Since releasing the Hybrid News Theme I have been contacted by a number of people on the ProNet mailing list asking me to shed some light on the process of creating template sets, or themes as most other products call them, for Movable Type. As I embark on creating this documentation I stumbled across a video made by a friend of mine on the same subject (mental note: subscribe to plasticmind.tv).

Jesse does a good job I think I showing that template sets are sincerely not that difficult and that anyone who can cobble together a WordPress theme, can easily create one for Movable Type. I would like to mention another tool at your disposal which will make this process even easier: it is called exportts. The program is a simple perl script that you can drop into your Movable Type tools directory to easily export the templates in a blog and then package them up as an installable template set or theme. All in one simple step.

The exportts tool is something I find indispensable in my work as it saves me literally hours of monotonous and menial labor. Its readme should explain exactly how it works if you want to learn more.

I hope this video helps though, while I document the process more thoroughly.

A blog is only as good as its links.
–Ancient Proverb

This plugin assists authors, editors and administrators in making sure that all of the links on their blog are still valid and therefore useful to their readers. It works by surfacing a additional list action called "Validate Links" in your Manage Entries table listing. Just select the entries you want to scan and evaluate, hit "Go" and this plugin will produce a simple report about all of the URLs found in the post.

The plugin will scan for all URLs including:

• valid references to embedded images
• outbound links
• frame references

Prerequisites

You will need to download and install the following Perl Module for this plugin to function:

• HTML::SimpleLinkExtor

Download

• Download 0.93

Installation

This plugin is installed just like any other Movable Type Plugin.

Screenshots

Selecting Entries to Check

Link Check Report

License

This plugin is licensed under the GPLv2.

TODO

• Process comments for links
• Night emails to check past posts for invalid links.
• Do not surface list action item is prereq is not installed, or provide a good error message.

The Photo Gallery Plugin for Movable Type does more than provide a photo blogging theme for Movable Type users, it transforms the Movable Type user interface to make managing, editing and uploading photos easier.

Prerequisites

• This plugin makes use of the Image::ExifTool perl module. The module is optional. When installed it will give you the option of setting the date of the photo to the current date or the date the photo was actually taken.

• This plugin surfaces a number of theme options which require you to install the Movable Type Configuration Assistant plugin version 1.01 or greater.

• This plugin utilizes Mark's Order plugin.

Download

• Photo Gallery

Bug Reports

The Photo Gallery plugin is constantly being improved. Please submit bug reports via the following approved mechanisms:

• Visit the Lighthouse Project for Photo Gallery
• Submit a bug via email

Features

• Quickly install a professionally design photo gallery to your web site that is seamless extension of the popular "Mid-Century" blog theme for Movable Type.
• Multiple layouts for the front door, including a traditional photo blog layout, or a grid layout in which thumbnails predominate.
• Feature photos on the front door of your photo blog using the @featured tag.
• Utilize an enhanced photo management screen that replaces Movable Type's default Manage Entries and Manage Assets screens.
• Use a stream lined and enhanced upload wizard which replaces Movable Type's default Upload File dialog.

Documentation

Installation

To install this plugin follow the instructions found here:

http://tinyurl.com/easy-plugin-install

Usage: Uploading Photos and More

Check out: Using Photo Gallery

About Mid-Century Photo Gallery

This theme is open source and based upon the amazing design work of Jim Ramsey. It is designed to be a seamless extension of his popular Movable Type theme called Mid-Century.

Release Notes

Stop Design/Doug Bowman's Templates

Starting with version 2.2 of this plugin, the popular Stop Design Photo Gallery Templates are no longer included in this plugin, and sadly, no longer supported. They simply were too complex and costly to support going forward. However, for users wishing to have access to those templates, they may download the Stop Design Gallery Theme separately.

Upgrading from Photo Gallery 1.0

See "Upgrading Photo Gallery."

Thanks to the Blog Herald's quick write up on the new Mid-Century Photo Gallery plugin I have gotten a number of volunteers to help test out the first builds of the newly refactored Photo Gallery plugin for Movable Type.

Here is a quick run-down of what I have done with the code and decisions I have made to make it easier to work with:

• I have factored out Doug Bowman's Stop Design templates into a different plugin. This new plugin relies on the Photo Gallery plugin to operate. You can download this plugin as well.

• I have turned the Photo Gallery plugin into more of a framework. Any template set that adds the photo_gallery => 1 key to their registry will automatically convert Movable Type's user interface into a more approachable photo management application.

• The Mid-Century Photo Gallery Theme can be found in the Photo Gallery plugin and there I will maintain it as a reference implementation of a Movable Type photo gallery.

• I have decided to discontinue free support for Doug Bowman's templates. They are simply too complex to do for free. If you rely on these templates for your site, I would be happy to support them as part of a services engagement.

Other things to note:

• You will need to install the perl module Image::ExifTool.

• Photo Gallery in its current form works for me. I cannot guarantee that it will work for you, but that is why I need your help. Please install it and let me know if you encounter any problems.

I hope everyone enjoys the new theme! Download PhotoGallery 2.2a now.

Update - 2/19/2009: Next set of builds available: Download PhotoGallery 2.2b now. This fixes A LOT of bugs.

Update - 2/21/2009: I have created a homepage for this plugin.

I am the architect and author of virtually all of Movable Type's documentation online, and I continue to provide services to Six Apart in order to expand their efficacy. In addition, I have provided training services to some of Six Apart's largest customers and can instruct individuals and teams on a variety of topics. Training services can be provided on-site or off according to each client's needs and schedule.

Courses

User Training - This 1 day course will provide authors, editors and administrators with the basics of using and administering their Movable Type CMS. 
Subjects include: site administration, content creation, pages, user administration and permissioning, the basics of site modification and customization, an overview of 3rd party plugins, and a comprehensive review of the entire application and what it can and cannot do.

Designer Training - This 1 or 2 day course provides designers with the tools and knowledge they need to become adept at designing and customizing web sites powered by Movable Type. Students finishing this course will have a strong foundation of knowledge in Movable Type's templating language, template module caching, template sets and theme creation, commonly used third party plugins, and site/publishing optimization.

Developer Training - This 1 or 2 day course teaches any developer how to build plugins to extend the core Movable Type application. Subjects include the Movable Type Registry, working with Movable Type objects, building custom data types, callbacks and events, working with jQuery and Movable Type's Javascript, creating new screens in the Movable Type application, and much, much more.

Operations Training - This 1 day course teaches system administrators on how to host and operate Movable Type. Students leaving the course will have strong understanding of how to optimize Movable Type, the Movable Type Publish Queue, and how to build out Movable Type clusters and network architectures that scale.

Movable Type and Perl for PHP Developers - this 1 day course is designed for PHP developers wishing to learn the basics of Perl, but most importantly how to apply their knowledge of PHP to developing web sites in Movable Type.

Learning Perl - this 5 day course can take virtually any person with a very basic understanding of scripting/programming and teach them the basics of the Perl programming language. This course is ideal for companies wishing to teach engineering, QA and operations teams the basics of the language and to prepare them for other courses designed to teach them the basic of developing custom applications and plugins for Movable Type.

Custom Package - Clients are also free to build a custom curriculum based upon their specific needs.

Full course outlines available upon request.

Javascript

Byrne is an experienced Javascript developer and has developed large scale applications that depend entirely upon either YUI or jQuery. See also:

• Tag Control for YUI - A simple widget to make the addition and removal of tags simple and intuitive.


• Filter Control for YUI - A widget, or UI control that automates the creation of a progressive filtering mechanism.

PHP

In addition to being an experienced Perl developer, Byrne is also incredibly versed in PHP. He has developed numerous large scale web applications build upon PHP as well as numerous open source libraries in use by sites across the Internet. See also:

• Test Run - A large scale test case management solution written entirely in PHP serving thousands of customers.


• MyPHPGoogleCheckout - An open source library for integrating with Google Checkout.


• PHP Paginator - A simple open source library that makes generating links to pages within a result set almost too easy.


Perl

Byrne is an experienced Perl programmer having served as the lead developer of the popular SOAP::Lite toolkit, and continuing to be one of the Movable Type's leading plugin developers and contributors.

A recent article written by chromatic in which he identifies mod_perlite as of the top 5 features Perl 5 needs right now has motivated me to try and the fire lit under those interested in this project again. I have launched a new website (thanks to Aaron who got the domain), powered by Perl and Movable Type of course, to help marshal the community.

For those of you unfamiliar with mod_perlite, it is a project conceived from a desire to make deploying and programming Perl based web applications, as effortless as it is to build PHP applications. It is founded on a belief that it is not Perl that is outdated, it is CGI. What the Perl community and hosting providers need is a Perl interpreter that is embedded in the web server as a module, and a Perl run time environment that is stateless - thus avoiding the pitfalls of memory leaks and the like that wreak havoc in shared hosting environments.

Are you a Perl hacker and know a little bit about mod_perl and how to bind the Perl interpreter into Apache - then we could really use your help. Please consider joining the project to help us get going again! We already have working code, we just need to address some edge cases. Visit the project's homepage to figure out how to help.

Without a doubt the most common support request I receive from users of my many Movable Type plugins is around installation. If you are having difficulty or getting frustrated the first and most important thing to realize is that it is not your fault. Not in the slightest. The problem lies in having poor documentation which exists because plugin authors, like me, take plugin installation for granted. As a result our instructions, while well intentioned, are sometimes not sufficient for all users.

So permit me to try to explain how to install a Movable Type plugin once and for all and in a way that I hope will be useful and understandable by the largest possible number of people.

Before You Begin

First off, these instructions assume that you are installing a plugin that adheres to the documented best practices for plugin packaging. To determine if the plugin you are installing adheres to this standard you will need to unzip the plugin on your local computer, which should create a new folder containing all of the files needed to run the plugin. Look inside this folder, if it contains another folder called plugins then you are in luck. If not, then this guide will be of little use to you. I would encourage you to contact the plugin author and ask them to please repackage their plugin according to the documented standard, or point them to me so I can help them.

Your $MT_HOME and $MT_STATIC Directories

You are clearly on the right track. Now, another thing you need to know is that these instructions make frequent reference to your "$MT_HOME" and "$MT_STATIC" directories. The location of these directories will be different for virtually everyone; what is important is knowing where these directories are for you.

The $MT_HOME directory is a cgi-bin directory where you have the Movable Type application installed. Let's look at this common example: suppose you have installed Movable Type into the following directory:

/var/www/cgi-bin/mt

We know that this is the right directory because if you view its contents you will find within it a file called mt.cgi like so:

/var/www/cgi-bin/mt/mt.cgi

This is your $MT_HOME directory.

Now, your $MT_STATIC directory is where you will find Movable Type's static files. Like with Movable Type itself, you may¹ need to place the plugin's static files outside of your $MT_HOME directory into a "web accessible" directory. You will know this is the case for you if you access Movable Type from a URL like:

http://foo.com/cgi-bin/mt/mt.cgi

And your images are served from a URL like:

http://foo.com/mt-static/images/movable-type-logo.gif

Alternatively, your system may be configured such that static files can be served directly from your cgi-bin directory like so:

http://foo.com/cgi-bin/mt/mt-static/images/movable-type-logo.gif

Knowing how your system is configured to serve static files is essential to a successful plugin installation. To find your $MT_STATIC directory, find on your system a file called mt.js. Let's suppose that your system tells you that mt.js can be found in:

/var/www/htdocs/mt-static/mt.js

Then your $MT_STATIC directory is:

/var/www/htdocs/mt-static/

If your system finds more than one copy of mt.js you will need to do some sleuthing to figure out which one of these directories is in use by Movable Type. Hint: consult your mt-config.cgi file; in it might be a configuration parameter that will indicate the proper path to the directory in question.

Now, let's proceed with your installation.

Installing via the Command Line (Unix)

If you are at all familiar with using the command line, then this is without a doubt, the quickest and most straightforward solution to plugin installation:

prompt> unzip SomePlugin-1.3.zip
prompt> cp -a SomePlugin-1.3/* $MT_HOME/

This will copy all of your files into the appropriate directories, including the plugin's cgi scripts, and Perl library files and sometimes even its PHP files needed to support dynamic publishing².

And optionally, if the plugin has an mt-static folder and your system requires you to install static files into a different directory than your $MT_HOME:

prompt> cp -a SomePlugin-1.3/mt-static/* $MT_STATIC/

Installing via the Command Line (Mac OS X)

Installing a plugin on a Mac is almost identical to installing on in Unix. The only difference really is the cp command used since cp -a is not supported. So the command sequence becomes:

prompt> unzip SomePlugin-1.3.zip
prompt> cp -pR SomePlugin-1.3/* $MT_HOME/

This will copy all of your files into the appropriate directories, including the plugin's cgi scripts, and Perl library files and sometimes even its PHP files needed to support dynamic publishing².

And optionally, if the plugin has an mt-static folder and your system requires you to install static files into a different directory than your $MT_HOME:

prompt> cp -pR SomePlugin-1.3/mt-static/* $MT_STATIC/

Installing via FTP

If you are installing the plugin via FTP, then the instructions are similar as to the above, but you will be installing the plugin by dragging and dropping files around. Whee! Of course, your exact instructions may vary depending upon the FTP software you use, but the general gist is the same no matter what. Let's take a look:

1. Unzip the plugin's zip file to your desktop.

2. Start your FTP client and connect to your web server.

3. In your FTP client navigate to your $MT_HOME directory.

4. Select all of the files found in the folder created when you unzipped the plugin's archive and drag and drop them directly into your $MT_HOME directory in your FTP client. Wait for all of the files to be copies.

5. In your FTP client navigate to your $MT_STATIC directory.

6. Select all of the files found in the mt-static folder found in the folder created when you unzipped the plugin's archive and drag and drop them directly into your $MT_STATIC directory in your FTP client. Wait for all of the files to be copies.

And you are finished. Granted, textual instructions like that can sometimes not be very intuitive, so check out the screencast below which demonstrates the instructions above more precisely:

Movable Type Plugin Installation Demo from Byrne Reese on Vimeo.

And that's it. Hopefully this will answer the questions most people have about installing Movable Type plugins. If you have trouble installing one, drop me a note and I will try to help.

¹ - You may or may not need to perform this extra step, which depends exclusively upon how your web server has been setup. As for me, I prefer to configure my web server such that I can serve images and javascript file (static files) from my cgi-bin directory.

² - Some plugins come with a set of PHP files that are used by Movable Type's dynamic publishing system. These files should get installed into your `MT_HOME/php` directory, and *not* into your mt-static directory. But if you follow the instructions in this document, you shouldn't have to worry about this.

Three weeks ago my wonderful and fruitful tenure at Six Apart came to an unexpected and abrupt end when the company laid me and 8% of my friends coworkers off. In the wake of my dismissal I tried to understand why such a dedicated and passionate employee with so many accomplishments, with such a deep knowledge of each of their many products and who, as a former coworker told me, was "part of the DNA of the company" could be cut loose.

The more I thought about it though, the more I realized that it is just too easy to be bitter, and that the truth is that I have so much more to be proud of and thankful for having worked there: such as playing an important role in the invention of OpenID, helping to drive one of the most successful launches in Six Apart's history and spear heading the effort to open source Movable Type. In fact, it is my having worked there that may very well be what saves me in the end. Following what few initial slightly ambiguous tweets I did make regarding my change in status, I was inundated with email not only from friends, but also and more surprisingly from readers and followers of my blog that I didn't even know I had.

The influx of inquiries, offers of freelance work, job referrals and simple words of encouragement made me conscious for the first time of the extent of the network I was building just by doing and sharing with people what I love and do best: creating. And I can't help but think that the knowledge, experience and connections made while at Six Apart had a little something to do with the amazing network of friends, followers and supporters I now know I have.

So, now I begin to look forward, past the upset and disappointment of having been laid off from a company I love and admire, and towards a future I may otherwise have never been able to imagine for myself. What that future is however has not fully taken shape, as there is surprisingly a great deal of opportunity out there.

I would be curious what friends and followers of this blog think I should do? Should I venture off on my own? Try to make something of Test Run? Become a premiere Movable Type consultant? Join a new and innovative company? Or, considering the economic climate, play it safe and join something more established? Let me know what you think:

As I am in the process of deciding what is next for me, I am also looking for contract work that will allow me to make this decision in my own time. I already have some exciting projects lined up and that I am working on, but I am looking for more. So if you, or someone you know needs help, there are few who know more about Movable Type. Drop me a line and let me know what you need help with, be it Movable Type, PHP, Perl, TypePad, blogging, or Product Management.

The Super Page plugin for Movable Type was created in support of Movable Type's documentation effort. The basic need was this:

• convert a single, massive page into a set of paginated, easy to navigate pages broken up by chapter/section.

This plugin solves that problem by allowing authors to flag a regular Movable Type page as a "Super Page." When that page is saved, the plugin will automatically partition it into multiple pages and generate a table of contents for the Super Page. The plugin also makes available a set of template tags that allow you to construct next page and previous page links for all of the child pages derived from the parent Super Page.

Each "child page" is delineated by a HTML header.

Download

• Download Super Page 0.96

Reporting Bugs

Super Page is constantly being improved upon. To report a bug please use the following resources:

• Super Page in Lighthouse

• Report a bug via email

Installation

To install this plugin follow the instructions found here:

http://tinyurl.com/easy-plugin-install

Usage

• To mark a page as a "super page" edit the page in question and under "Publishing" toggle the "Super Page?" checkbox. Then save the page and the child pages will be created for you automatically.
• When you delete a super page, all of the child pages will be deleted as well. This cannot be undone.
• Child pages will inherit all of the parent page's properties vis-a-vis commenting.
• A table of contents page with a basename of 'index' will be created for you automatically in markdown.

Caveats, Known Issues and Warnings

• Super Pages must be formatted in markdown
• All headings, which map to the titles of each child page must be unique. When you change a heading, and thus a page title, comments on that child page will be permanently deleted. PLEASE BE CAREFUL if you want to preserve these comments.

How It Works

Super Page works with pages that have been formatted in Markdown. It divides the document into "sections" based upon markdown headers. Markdown headers are those lines that begin with one or more pound (#) characters, and get translated into <h1>, <h2>, etc HTML tags. Every header then becomes the title of a section, which in turn becomes the title of the page that is created by Super Page.

When you mark a page as a super page, the plugin attaches meta data to that page and flags it as the "parent page." Each child page that results from that parent page is also flagged accordingly. Additional meta data is attached to each child page to help indicate and track which page is the next and previous page in the sequence resulting from parsing the parent page into multiple child pages.

When a super page is updated in the system, the Super Page plugin partitions that page into its constituent sections. Then it attempts to locate and then update each section that was previously generated with the newly updated content from the parent page. This way, if child pages accumulate comments, those comments are preserved.

Super Page identifies pages based upon the section title or header tag. Therefore, by changing the title of a section, you risk losing any comments that may have been attached to that page by your community.

Template Tags

Super Page makes the following template tags available to help construct navigation links between pages.

• <mt:IsSuperChildPage> - returns true if the current page is the artifact of a super page
• <mt:IsSuperPage> - returns true if the current page is a super/parent page
• <mt:PrevPageID> - returns the page ID of the previous page in the super page
• <mt:NextPageID> - returns the page ID of the next page in the super page
• <mt:ParentPageID> - returns the page ID of the parent super page

Sample Template Code

<mt:IsSuperChildPage>
<p>This is a super page!</p>
<ul>
<mt:if tag="NextPageID" ne="">
  <li>Next: <mt:NextPageID setvar="next">
    <mt:Pages id="$next"><a href="<mt:PagePermalink>"><mt:PageTitle></a></mt:Pages></li>
</mt:if>
<mt:if tag="PrevPageID" ne="">
  <li>Prev: <mt:PrevPageID setvar="prev">
    <mt:Pages id="$prev"><a href="<mt:PagePermalink>"><mt:PageTitle></a></mt:Pages></li>
</mt:if>
  <li>Parent: <mt:ParentPageID setvar="parent">
    <mt:Pages id="$parent"><a href="<mt:PagePermalink>"><mt:PageTitle></a></mt:Pages></li>
</ul>
</mt:IsSuperChildPage>

Example

Let's suppose I have a super page called "Test Page" who contents are:

# Overview

yadda yadda yadda

## About the Author

yadda yadda yadda

### Where to find more

yadda yadda yadda

## My Article

yadda yadda yadda

The pages that will result are:

• Overview
• About the Author
• Where to find more
• My Article
• Test Page: Table of Contents

Licensing

Super Page is licensed under the same terms of Perl itself.

The Forum Utilities plugin is an add-on for the Movable Type Publishing Platform that provides a collection of tools and utilities often found in forum software to help enhance and elevate the quality of conversation among commenters and visitors. Its features include:

• Promote Comments to Entries - convert a lengthy or quality comment to a full fledged post on your blog or forum to give it the attention and visibility it deserves.
• Feature Comments - editors can easily flag a comment as a featured comment so that you can more easily bring attention to good comments in your templates.
• Close a Discussion - easily and quickly close comments on an entry from the Manage Entries screen.

Download

• Forum Utilities 0.91

Installation

To install this plugin, follow these simple steps:

1. Download the plugin and unzip it on your Desktop
2. Copy/upload the contents of Desktop/ForumUtils-1.0/mt-static into /path/to/mt/mt-static on your web server.
3. Copy/upload the contents of Desktop/ForumUtils-1.0/plugins into /path/to/mt/plugins on your web server.

Documentation

Promoting Comments to Entries

Every once in a while a user leaves a comment on your blog that is insightful enough, or long enough that it almost feels like it should be a post in and of itself. Or perhaps it is a comment that has spawned a rich conversation that has taken on a life of its own and you do want it to distract too much from the main topic at hand. Or perhaps the comment could potentially attract a lot of eyeballs and you want to capture that ad revenue.

When comments are promoted, the plugin will take care of all of the following for you:

• Create an entry containing the text of the comment
• Make the commenter the author of the newly created entry
• Transport the entire thread of comments associated with the comment and make them comments on the newly created entry
• Flag the comment left behind as having been promoted
• Flag the new entry as one that has been promoted from a comment

Template tags are then made available so that designers and site admins can style and message as they see fit around promoted comments and entries.

How to Promote Comments

Editors and administrators can promote comments in one of two ways:

1. From the Manage Comments listing screen, select "Promote to Post" from the list actions pull down menu found at the top of the table listing. This makes it easy to promote multiple comments at once. The plugin will prompt you for a post title for the post you are about to create.

   

   When promoting comments from the list view, all selected comments will be promoted to entries and published. When complete the user will be redirected to the comment listing screen. If you prefer to edit the entry prior to publishing it, please promote comments from the Edit Comment screen described below.

2. From the Edit Comment screen, select "Promote to Post" from the sidebar. When promoting a comment from the Edit Comment screen an entry will be created but be left in an unpublished state, allowing the editor to augment the entry with additional content and a preferred entry title.

   

Featuring Comments

Here are a couple ways people might use this feature:

• Featured Comments - simply flag a comment as insightful on your blog, give it a different background color, or put a star next to it.
• Answers Forum - in the context of an answers forum, this feature could be used to flag a comment as "the answer" or as "helpful."

To flag a comment is featured, or to turn a featured comment into an unfeatured one, select the comment you want to feature from the comment listing table on the Manage Comments Screen. Then select "Toggle Featured" in the pull down menu at the top of the table listing.

Closing Comments on an Entry

A new list action was created to simply make closing comments on posts more convenient. This feature allows admins to close comments on multiple entries at a time, directly from the Manage Entries screen.

Template Tags

CommentIsPromoted

This is a block or container tag whose contents will be output if the current comment in context has been promoted to an entry.

<mt:Comments>
   <mt:CommentIsPromoted>
     <mt:setvarblock name="eid"><mt:CommentPromotedToEntryId></mt:setvarblock>
     <mt:Entries id="$eid">
       <p>This comment has been promoted to an entry entitled 
       <a href="<mt:EntryPermalink>" class="promoted"><mt:EntryTitle></a></p>
     </mt:Entries>
   <mt:Else>
      <mt:Include module="Comment Detail">
   </mt:CommentIsPromoted>
</mt:Comments>

CommentIsFeatured

This is a block or container tag whose contents will be output if the current comment in context has been flagged as a featured comment.

The code same below adds a CSS class to the comment <div> so that it can be styled differently for featured comments.

<mt:Comments>
   <div class="comment<mt:CommentIsFeatured> featured</mt:CommentIsFeatured>">
      <mt:Include module="Comment Detail">
   </div>
</mt:Comments>

CommentPromotedToEntryId

This template tag outputs the Entry ID that the current comment has been promoted to. This tag can be used to load the related entry and generate a link to it.

<mt:setvarblock name="eid"><mt:CommentPromotedToEntryId></mt:setvarblock>
<mt:Entries id="$eid">
  <p>This comment has been promoted to an entry entitled 
  <a href="<mt:EntryPermalink>" class="promoted"><mt:EntryTitle></a></p>
</mt:Entries>

EntryPromotedFromCommentId

This template tag outputs the Comment ID that the current entry was promoted from.

EntryWasPromoted

This is a block or container tag whose contents will be output if the current entry was previously a comment that was promoted.

License

This plugin is licensed under the same terms as Perl itself.

Help and Support

This plugin utilizes Movable Type's extensible Open Id Login framework to give a preferential and customized login experience for Yahoo! users on Movable Type blogs.

Prerequisites

Yahoo! is one of the first OpenID providers to implement OpenID 2.0. Movable Type is the first to provide bundled support for consuming OpenID 2.0 identities. Therefore, you will need to the following installed to utilize this plugin:

• Movable Type 4.2
• Crypt::SSLeay Perl Module

Screenshot

Download

• YahooOpenId-1.04.zip

Installation

Unzip the file you download on the server you wish to install this plugin.

• Copy the contents of the mt-static folder into Movable Type's mt-static folder. Be sure to preserve the directory structure.
• Copy the contents of the plugins folder into Movable Type's plugins folder. Be sure to preserve the directory structure.

Documentation

Once the plugin has been installed you can enable Yahoo! authentication by navigating to the "Registration" section found under the Preferences > Blog Settings menu. Click the check box next to "Yahoo!" and click "Save Settings."

This plugin will work with dynamic and static publishing.

License

This plugin is licensed under the GPL.

Not to long ago I began work on a very cool new theme, or Template Set, for Movable Type. I had built out all the templates and nearly completed all of my work without having to write a single line of Perl code, which was one of those unstated design goals for the project because let's face it, no one should have to write a single line of code, be it Perl, PHP, Python or Ruby, to create a theme for any blog and web site. That is outside the skill set of a typical designer.

But then I got to a point in the project where I wanted to surface configuration options to the user for the theme.

Byrne, meet Wall. Wall, meet Byrne. Smack.

That is when the "unstated design goal" permuted into a new proposal and prototype for how Movable Type can be extended in the future to support 100% perl-less plugins. No kidding. The experimental plugin is called "Movable Type Configuration Assistant."

How it Works

Say you are a designer. You want to build a theme for a web site that someone can just drop in to their blog and have it work. You also want to make the theme configurable while keeping your users from having to know anything about HTML, CSS, PHP or Perl themselves. Just fill out a form and be done with it. Here's the challenge: you don't know how to do that because while you know HTML and CSS like the back of your hand, your knowledge of Perl and/or PHP is some what lacking.

Enter Configuration Assistant.

Configuration Assistant for Movable Type allows you to easily design an entire settings page for your theme or plugin complete with field sets, labels, default values, pull down menus, radio buttons, check boxes, text areas, and text input fields for all the options you wish to expose. You can do this all through a simple config file. Did I say that no perl is required?

The settings a user then saves using this form will automatically be made available to you, the designer, through a set of template tags you choose and that you can use within your templates. Here is a simple example:

Here is an excerpt from a Movable Type config.yaml file that will define two settings for your plugin:

id: MyPluginID
name: My Plugin
blog_config_template: '<mt:PluginConfigForm id="MyPluginID">'
plugin_config:
    MyPluginID:
        fieldset_1:
            feedburner_id:
                type: text
                label: "Feedburner ID"
                hint: "This is the name of your Feedburner feed."
                tag: 'MyPluginFeedburnerID'
            use_feedburner:
                type: checkbox
                label: "Use Feedburner?"
                tag: 'IfFeedburner?'

This is the settings page it creates:

And here is the template code that utilizes the tags it auto-creates for you:

<mt:IfFeedburner>
  My feedburner id is <mt:FeedburnerID>.
<mt:Else>
  Feedburner is disabled!
</mt:IfFeedburner>

Documentation

• Read the complete README.txt file found inside the plugin.
• MTOS Proposal

Status of the Plugin

This plugin is a prototype for something I believe strongly should be in the core of Movable Type. I have built this plugin to serve as a working example for a proposal made to the Movable Type Open Source community.

The plugin needs additional refinement before being fully integrated. Namely:

• this plugin should extend the existing settings registry key as opposed to defining its own plugin_config registry key.
• this plugin should support additional form elements like radio, multiple checkboxes, and more.
• simplify the semantics of the configuration options.
• this plugin needs to be used by users, have its documentation completed, and be more thoroughly tested.
• this plugin needs endorsements and approval from the community.

Download

I need help testing this concept. Please consider downloading it and playing around with iit:

• Download 0.9

Recently I received a comment on a post about modperlite alleging that modphp, an Apache module mod_perlite is modeled after, is falling out of favor with hosting providers. That is quite an allegation - one that I initially shrugged off because it seemed preposterous to me. I mean just consider for a moment all of the incredibly popular applications including WordPress, Drupal, PostNuke, phpBB, Mediawiki and many more too numerous to list here let alone count that all rely on PHP exclusively.

Not wanting to completely discount this comment I decided to consult a close acquaintance of mine that works with one of the most popular hosting providers on the Internet. In working with him on a number of projects I have come to respect him on a number of levels, but especially for his knowledge of operations and system architecture. He spends a great deal of his time every day trying to maintain systems running software he didn't write or install on machines run by users he has little or no control over. He is an expert in cleaning up after others. So I asked him if he had an opinion about this statement.

What I learned through our email dialog was enlightening, and I wanted to share it with a larger audience. He permitted me to republish parts of our correspondence, but asked to remain anonymous. (Editorial note: I have taken some of his text and elaborated as best that I could in order to provide a more complete overview of this issue.)

This is a rather multifaceted issue, but to summarize I'd venture that mass virtual hosting on the whole is trending away from mod_php/mod_perl.

He proceeded to back this claim up:

• Real file I/O is impossible or insecure - it is difficult to harden a mod_perl/mod_php application because these Apache modules only run in the permissions context of the web server's user. Software that helps resolve this issue, like suPHP, which allows a script to run in the permissions context of the script's owner, negate the performance benefits of the underlying mod_perl/mod_php module.

• One of the more viable solutions to this permissions dilemma, an Apache module called mpm_perchild, died on the vine years ago. "This was the Apache 2+ intended answer for the security problem and was supposed to (correctly, IMO, given Apache's architecture) have each request thread out based on file ownership, sort of a rolled in suexec."

• "There is growing adoption of code frameworks (rails, django, catalyst, etc etc) that just don't play with mod_php/perl. Building an effective cgi/fastcgi architecture covers bases better."

• "There is a growing adoption of very powerful web servers like lighttpd and nginx whose only interface is cgi/fastcgi. To many developers today Apache really is an anachronism."

• "Another side effect of cgi/fastcgi that I neglected to mention is that it is much more apparent which users' code/processes are monopolizing resources" thereby making it easier for hosting providers to monitor, enforce resource utilization policies and recover from systems under load.

Then y friend also responded to this comment:

@saj - really? You think mod_php is falling out of favor? That is quite a statement... one that I can't imagine is true. PHP is one of the most ubiquitous web scripting languages, second only to Perl. A cannot imagine hosts degrading their support for this language.

With this response:

I think this is the most important misconception to dispel. In an Apache vhosted setup, modphp *is* degraded support. Settings like safemode are generally implemented and users don't have access to edit their own php.ini, relying on .htaccess hackery to eke out the limited php settings customization available.

He concluded, "there is a ton more to the issue and these points really don't do it full justice."

Now lets be real, I don't think my friend is saying that hosting providers will drop support for PHP, not in the foreseeable future, but if hosting providers tend not to prefer mod_perl and mod_php based applications what will this mean for all us developing on top of these languages and deployment platforms?

And ask yourself, when you write a web based application, are you thinking about the company that is going to be hosting your application for your customers/users? And what are you doing for them to make their lives easier?

I have had a theory for a long time that perl based CGI scripts could be sped up considerably by simply by keeping the interpreter resident in memory. Not only that, but the module that makes that possible wouldn't be a pain in the ass to install because of a key design goal: simplicity, borrowing heavily from a module that I think does a lot right, mod_php.

Well, if you followed the thread you would have noted that Aaron just recently got a version of mod_perlite to work against basic CGI functions. Totally awesome.

Next step: benchmarking. There are some skeptics out there, and those skeptics are a helluva lot smarter then me, so I have to see for myself: does this approach have actual merit?

And if the theory holds water, then I will setup a homepage for the project, get some builds spun up, and start working on documentation. For those of you who expressed interest in helping, by all means check out the latest from subversion and give mod_perlite a whirl.

Over the many years of their coexistence, the terms CGI and Perl have become virtually synonymous. This perception that CGI and Perl are one and the same has contributed to some small degree to the perception that Perl is outdated and an inappropriate language for web programming - unlike its more modern counterparts like Ruby or PHP.

I of course know this to be a complete fallacy. First of all, the company I work for is a devout Perl shop and our products, all written in Perl, are collectively some of the largest and most scalable on the Internet. Few other companies in fact present more widely attended seminars and tutorials about scaling for the Web then ours do at conferences like eTech and OSCON.

But perhaps the more significant fallacy is that CGI and Perl are synonymous. In actuality, they technically have very little to do with one another, and there is technically no reason one should be hampered by the other, despite all evidence to the contrary.

A little history and background

CGI stands for "Common Gateway Interface" and was invented to allow any script, written in any scripting language, to also act as a web based application. In the early days of the Internet this was incredibly helpful to the first Web programmers (a.k.a. system administrators) proficient in sh, bash, csh, tcsh and perl because it allowed them to quickly deploy simple web based automation tools based on scripts and libraries they had already written. Cool.

But the inherent flexibility of language agnosticism is also CGI's greatest liability, and also by association, Perl's as well. You see, CGI is based upon the principle that when the web server receives a request, it does not know what scripting language will interpret that request. Therefore, it defers processing directly to the operative system, and so must do something geeks call "forking and exec'ing" - or in other words, the web server must start up an entirely new process on your server to handle the request. This may not sound like a big deal, but it sometimes can be as each forked process holds the entire Perl interpreter in memory. And that is a big deal. First it can consume a lot of your server's memory, and depending upon the size of your application, it can be slow to initialize. It works - and works well by virtue of working, but it by no means ideal.

More modern languages have been designed to avoid this. Let's take PHP for instance. PHP is a language that was designed for web programming exclusively. Therefore its architects made a critical (perhaps even obvious) decision early on: if the web server is going to handle a lot of PHP scripts, why bother forking a process to determine what scripting language will handle the request (this is expensive) - why not just load the PHP interpreter into memory once and interpret the request within the web server (which is much cheaper)?

So when it comes to CGI vs PHP, it is not really about Perl vs. PHP at all. It is really about understanding two solutions to two different problems - one operating under the assumption that every request will be processed by the same interpreter and the other designed to execute any script via the web.

The solution as it stands today

In the Perl world, there are actually two Apache modules that attempt to do what PHP does inherently: load the Perl interpreter into memory so that you no longer have to spawn a new process each and every time your web server receives a CGI request. Those two modules are mod_perl and mod_fastcgi.

However, these two modules have a critical flaw: they are incredibly complex because they attempt to solve a huge problem set having to do creating a persistent and stateful execution context. The result are two modules that are not only too heavy weight for the average user but also incredibly difficult to install - even for myself.

How to actually fix the problem

The more I have thought of this problem, the more I have come to believe that there is little standing in Perl's way to have all of the benefits that PHP has gained from being a language designed exclusively for the Web.

In theory, one should be able to take the source code of mod_php (the Apache module that dispatches web requests to a PHP interpreter) and swap out the component responsible for dispatching a request to PHP for one that dispatches the request to Perl. In theory it should just work (more or less). The result would be an Apache module that would be easy to install, and be much more efficient in handling and processing requests online.

Granted, this solution would not be stateful and persistent the way mod_perl and mod_fastcgi are, but that is not a problem this solution is engineered to solve.

Introducing mod_perlite

All of this is a really long-winded setup for what is a very quick conclusion.

I shared this hypothesis with an engineer at work, Aaron Stone, who shares a passion for Perl with me, but who also has a passion for operations. He took on this challenge and devoted part of his 20% time to testing this hypothesis.

The output of his work is called mod_perlite. It is largely derivative of PHP and is capable of processing Perl scripts quickly and efficiently. The next step of the project is to make it compatible with the CGI protocol, which can be done by gutting parts mod_cgi and dropping them into mod_perlite.

So far our results are promising, and it is possible that with a little hacking we may have just made Perl faster on the web and easier to deploy for everyone.

If you are interested in helping or participating in this project please let me know -- we could certainly use the help.