The most up-to-date documentation for Config Assistant can always be found in the plugin, or in source control.

Using Config Assistant for Theme Options

This plugin adds support for a new element in any plugin's config.yaml file called options, which is placed as a descendant to a defined template set. When a user of your plugin applies the corresponding template set then a "Theme Options" menu item will automatically appear in their "Design" menu. They can click that menu item to be taken directly to a page on which they can edit all of their theme's settings.

The static_version root-level element will trigger Config Assistant to copy files to the mt-static/support/plugins/[plugin key]/ folder, and the skip\_static root-level element will let you specify files not to copy.

id: MyPluginID
name: My Plugin
version: 1.0
static_version: 1
template_sets:
    my_awesome_theme:
        base_path: 'templates'
        label: 'My Awesome Theme'
        options:
            fieldsets:
                homepage:
                    label: 'Homepage Options'
                    hint: 'These options only affect the home page.'
                    order: 1
                feed:
                    label: 'Feed Options'
                    order: 2
            feedburner_id:
                type: text
                label: "Feedburner ID"
                hint: "This is the name of your Feedburner feed."
                tag: 'MyPluginFeedburnerID'
                fieldset: feed
            use_feedburner:
                type: checkbox
                label: "Use Feedburner?"
                tag: 'IfFeedburner?'
                fieldset: feed
            posts_for_frontfoor:
                type: text
                label: "Entries on Frontdoor"
                hint: 'The number of entries to show on the front door.'
                tag: 'FrontdoorEntryCount'
                fieldset: homepage
                condition: > 
                  sub { return 1; }
                required: 1
skip_static:
    - index.html
    - readme.txt
    - .psd
    - .zip

Using Config Assistant for Plugin Settings

To use Config Assistant as the rendering and enablement platform for plugin settings, use the same options struct you would for theme options, but use it as a root level element. The static element is also valid here. For example:

id: MyPluginID
name: My Plugin
version: 1.0
schema_version: 1
static_version: 1
options:
  fieldsets:
    homepage:
      label: 'Homepage Options'
    feed:
      label: 'Feed Options'
  feedburner_id:
    type: text
    label: "Feedburner ID"
    hint: "This is the name of your Feedburner feed."
    tag: 'MyPluginFeedburnerID'
    fieldset: feed
skip_static:
    - index.html
    - readme.txt
    - .psd
    - .zip

Using this method for plugin options completely obviates the need for developers to specify the following elements in their plugin's config.yaml files:

• settings
• blog_config_template
• system_config_template

Fieldsets

Fields can be grouped by fieldset, and fieldsets are "tabbed" on the Theme Options screen. This provides an easy way to organize all of your fields and present them to the user in a clear fashion.

options:
    fieldsets:
        homepage:
            label: 'Homepage Options'
            hint: 'These options only affect the home page.'
            order: 1
        feed:
            label: 'Feed Options'
            order: 2

In this example two fieldsets have been defined: homepage and feed, and this will generate two tabs of options on the Theme Options screen. Note that the fieldset keys (in this case homepage and feed) must be unique within your theme or plugin.

Fieldset Properties

• label - is the description displayed on the tab, and is also displayed at the top of the page.
• hint - is a space for you to provide more detail about the contents of this fieldset. It is displayed just above all of the fields in this fieldset
• order - Use integers to sort the order of your fieldsets on the tabbed interface.

Fields

Fields are easily defined with properties.

options:
    feedburner_id:
        type: text
        label: "Feedburner ID"
        hint: "This is the name of your Feedburner feed."
        tag: 'MyPluginFeedburnerID'
        fieldset: feed
    use_feedburner:
        type: checkbox
        label: "Use Feedburner?"
        tag: 'IfFeedburner?'
        fieldset: feed

In this example two options, or fields, have been defined: feedburner_id and use_feedburner. Note that the option keys (in this case feedburner_id and use_feedburner) must be unique within your theme or plugin.

Field Properties

• type - the type of the field. Supported values are: text, textarea, select, checkbox, blogs
• label - the label to display to the left of the input element
• show_label - display the label? (default: yes). This is ideal for checkboxes.
• hint - the hint text to display below the input element
• tag - the template tag that will access the value held by the corresponding input element
• condition - a code reference that will determine if an option is rendered to the screen or not. The handler should return true to show the option, or false to hide it.
• default - a static value or a code reference which will determine the proper default value for the option
• fieldset - specify which fieldset a field belongs to.
• order - the sort order for the field within its fieldset
• republish - a list of template identifiers (delimited by a comma) that reference templates that should be rebuilt when a theme option changes
• scope - (for plugin settings only, all theme options are required to be blog specific) determines whether the config option will be rendered at the blog level or system level.
• required - can be set to 1 to indicate a field as required, necessitating a value.

Supported Field Types

Below is a list of acceptable values for the type parameter for any defined field:

• text - Produces a simple single line text box.

• textarea - Produces a multi-line text box. You can specify the rows sibling element to control the size/height of the text box.

• select - Produces a pull-down menu of arbitrary values. Those values are defined by specifying a sibling element called values which should contain a comma delimited list of values to present in the pull down menu.

• radio - Produces a set of radio buttons of arbitrary values. Those values are defined by specifying a sibling element called values which should contain a comma delimited list of values to present as radio buttons.

• checkbox - Produces a single checkbox, ideal for boolean values, or a set of checkboxes. When using this type to display multiple checkboxes, use the values field option to provide a list of checkbox labels/values. Use the delimiter field option to specify how your list of checkbox options are separated. See "Working with Checkboxes."

• blogs - Produces a pull down menu listing every blog in the system. Warning: this is not advisable for large installations as it can dramatically impact performance (negatively).

• radio-image - Produces a javascript enabled list of radio buttons where each "button" is an image. Note that this version of the radio type supports a special syntax for the values attribute. See example below.

• tagged-entries - Produces a pull down menu of entries tagged a certain way. This type supports the following additional attributes: lastn and tag-filter.

• entry - Produces the ability to select a single entry via a small pop-up dialog. In the dialog, the user will be permitted to search the system via keyword for the entry they are looking for. This field type supports the field property of all_blogs, a boolean value which determines whether the user will be constricted to searching entries in the current blog, or all blogs on the system.

• page - Operates identically to the entry type except that it pulls up a list of pages in the selected blog (as opposed to entries).

• category - Produces the ability to select a single category via a drop-down listing.

• folder - Produces the ability to select a single folder via a drop-down listing.

• colorpicker - Produces a color wheel pop-up for selecting a color or hex value.

• link-group - Produces an ordered list of links manually entered by the user. Options of this type will have defined for them an additional template tag to make it easier to loop over the links entered by the user in your templates. See "Link Group Template Tags" below.

• file - Allows a user to upload a file, which in turn gets converted into an asset. An additional field property is supported for file types: destination which can be used to customize the path/url of the uploaded file. See "Example File" below. Files uploaded are uploaded into a path relative to the mt-static/support directory. Also, for each option of type file that defined, an additional template tag is created for you which gives you access to the asset created for you when the file is uploaded. See "Asset Template Tags" below.

• separator - Sometimes you will want to divide your options into smaller sections, and the separator facilitates that. This is a special type of field because there is no editable form to interact with and is informational only. Only the label, hint, order, and fieldset keys are valid with this field type.

Link Group Tags

For each option of type link-group that is defined, two template tags are defined. The first is the one specified by the user using the tag parameter associated with the option in the config.yaml. This template tag will be useless to most users as it will return a JSON encoded data structure containing all the links entered by the user.

The second template tag is the useful one. It is called <TAGNAME>Links. This template tag is a container or block tag that loops over each of the links entered by the user. Inside each iteration of the loop the following template variables are defined for you:

• __first__ True only if the current link is the first one in the list.
• __last__ - True only if the current link is the last one in the list.
• link_label - The label associated with the current link.
• link_url - The URL associated with the current link.

For example, look at this config.yaml:

my_links:
    type: link-group
    label: 'My Favorite Links'
    tag: 'MyFavorites'

This will create two template tags:

1. <$mt:MyFavorites$>
2. <mt:MyFavoritesLinks></mt:MyFavoritesLinks>

You can use them like so:

<p>My favorite links are: 
  <mt:MyFavoritesLinks>
    <mt:if name="__first__"><ul></mt:if>
    <li><a href="<$mt:var name="link_url"$>"><$mt:var name="link_label"$></a></li>
    <mt:if name="__last__"></ul></mt:if>
  <mt:Else>
    I have no favorite links.
  </mt:MyFavoritesLinks>
</p>

Asset Template Tags

For each option of type file that is defined, two template tags are defined. The first is the one specified by the user using the tag parameter associated with the option in the config.yaml. This template tag will return the Asset ID of the asset created for you.

The second template tag is <TAGNAME>Asset. This template tag is a container or block tag that adds the uploaded asset to the current context allowing you to use all of the asset related template tags in conjunction with the uploaded file. For example, look at this config.yaml:

my_keyfile:
    type: file
    label: 'My Private Key'
    hint: 'A private key used for signing PayPal buttons.'
    tag: 'PrivatePayPalKey'
    destination: my_theme/%{10}e

This will create two template tags:

1. <$mt:PrivatePayPalKey$>
2. <mt:PrivatePayPalKeyAsset></mt:PrivatePayPalKeyAsset>

You can use them like so:

<p>The asset ID of my key file is: <$mt:PrivatePayPalKey$></p>
<p>The URL to my key file is: 
  <mt:PrivatePayPalKeyAsset>
    <$mt:AssetURL$>
  </mt:PrivatePayPalKeyAsset>
</p>

Example File

The file type allows theme admins to upload files via their Theme Options screen. The file, or files, uploaded get imported into the system's asset manager. The path where the uploaded file will be stored can be customized via the destination field option.

Allowable file format tokens:

• %e - Will generate a random string of characters. The default length of the string is 8, but can be customized using the following syntax, %{n}e where "n" is an integer representing the length of the string.

Example:

my_keyfile:
    type: file
    label: 'My Private Key'
    hint: 'A private key used for signing PayPal buttons.'
    tag: 'PrivatePayPalKey'
    destination: my_theme/%{10}e

Example Radio Image

The radio-image type supports a special syntax for the values attribute. The list of radio button is a comma-delimited list of image/value pairs (delimited by a colon). Got that? The images you reference are all relative to Movable Type's mt-static directory. Confused? I think a sample will make it perfectly clear:

homepage_layout:
    type: radio-image
    label: 'Homepage Layout'
    hint: 'The layout for the homepage of your blog.'
    tag: 'HomepageLayout'
    values: >
      "plugins/Foo/layout-1.png":"Layout 1","plugins/Foo/layout-2.png":"Layout 2"

Working with Checkboxes

The option type of checkbox has two modes:

• a boolean mode (a single checkbox either on or off)
• a multi-select mode (multiple choices and options)

A single checkbox is ideal when needing to collect boolean values from users. For example, here is a theme option to enable/disable advertising on a web site:

enable_ads:
  type: checkbox
  label: 'Enable Advertising?'
  hint: 'Check this box if you want advertising to be displayed on your web site'
  tag: 'IfAdsEnabled?'

Your template tag should then be:

<mt:IfAdsEnabled>
   <!-- insert ad javascript -->
</mt:IfAdsEnabled>

Sometimes however you need to use checkboxes to allow the user to select multiple options that all relate to one another. Here is an example of how to use this field to allow users to specify which areas of a site should have ads enabled:

enable_ads:
  type: checkbox
  label: 'Enable Advertising?'
  hint: 'Check this box if you want advertising to be displayed on your web site'
  tag: 'AdsEnabled'
  delimiter: ';'
  values: 'Homepage;System: Profile, Reg, Auth;Entries;Pages'

You can then check to see if the theme option contains a specific value like so:

<mt:AdsEnabledContains value="System: Profile, Reg, Auth">
   <!-- insert ad javascript -->
<mt:else>
   <!-- do nothing? -->
</mt:AdsEnabledContains>

Or you can loop over all the selected values that have been checked:

<ul>
<mt:AdsEnabledLoop>
  <li>You checked <$mt:var name="value"$>.</li>
</mt:AdsEnabledLoop>
</ul>

Defining Custom Field Types

To define your own form field type, you first need to register your type and type handler in your plugin's config.yaml file, like so:

config_types:
  my_custom_type:
    handler: $MyPlugin::MyPlugin::custom_type_hdlr

Then in lib/MyPlugin.pm you would implement your handler. Here is an example handler that outputs the HTML for a HTML pulldown or select menu:

sub custom_type_hdlr {
  my $app = shift;
  my ($field_id, $field, $value) = @_;
  my $out;
  my @values = split(",",$field->{values});
  $out .= "      <ul>\n";
  foreach (@values) {
      $out .= "<li><input type=\"radio\" name=\"$field_id\" value=\"$_\"".
     ($value eq $_ ? " checked=\"checked\"" : "") ." class=\"rb\" />".$_."</li>\n";
  }
  $out .= "      </ul>\n";
  return $out;
}

With these two tasks complete, you can now use your new config type in your template set:

template_sets:
  my_theme:
    label: 'My Theme'
    options:
      layout:
        type: my_custom_type
        values: foo,bar,baz
        label: 'My Setting'
        default: 'bar'

Defining Template Tags

Each plugin configuration field can define a template tag by which a designer or developer can access its value. If a tag name terminates in a question mark then the system will interpret the tag as a conditional block element. Here are two example fields:

feedburner_id:
    type: text
    label: "Feedburner ID"
    hint: "This is the name of your Feedburner feed."
    tag: 'FeedburnerID'
use_feedburner:
    type: checkbox
    label: "Use Feedburner?"
    tag: 'IfFeedburner?'

And here are corresponding template tags that make use of these configuration options:

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

Deploying Static Content

Preparing the Static Content

If you've installed many plugins, you know that you must often copy content to [MT Home]/plugins/ and [MT Home]/mt-static/plugins/. For new users this can be a confusing task, and for experienced users it's one more annoying step that has to be done. But no more! Config Assistant can be used to help your plugin or theme copy static content to its permanent home in the mt-static/ folder!

Within your plugin, use the static_version root-level key to cause Config Assistant to work with your static content. This key should be an integer, and should be incremented when you've changed your static content and want it to be re-copied.

If you want to exclude some of your static content from the copy process, you can specify this with the skip_static root-level key, as in the examples.

skip_static:
    - index.html
    - readme.txt
    - .psd
    - .zip

skip_static builds an array of items to be excluded, which is signified with a leading dash and space. Files can be a partial match, so specifying an extension (such as .psd) will cause all files with .psd to not be copied. skip_static is not a required key.

On the filesystem side, you will want to create your folder and file structure inside of a static folder in your plugin envelope. Any files inside of this static folder (except those items matching skip_static) will be copied during installation.

Installing the Static Content

When installing your new plugin or theme, the static_version will trigger Movable Type or Melody to run an upgrade. During the upgrade, Config Assistant will copy static content to the mt-static/support/plugins/ folder, and will create a folder for its contents. (For example, after installing Config Assistant, its static files can be found in mt-static/support/plugins/ConfigAssistant/.)

Note that the mt-static/support/ folder must have adequate permissions to be writable by the web server; Movable Type and Melody will warn you if it does not. Also note that this path is different from where you often install static content, in mt-static/plugins/.

Developers may have reason to reinstall the static content; this can be done by running ./tools/static-copy.

Plugin-Specific Static Template Tags

Two template tags are created for your plugin or theme, to help you type less and keep code clean: [Plugin ID]StaticFilePath and [Plugin ID]StaticWebPath. For example, Config Assistant makes available ConfigAssistantStaticFilePath and ConfigAssistantStaticWebPath.

These tags will output the file path and the URL to a plugin's static content, based on the StaticFilePath and StaticWebPath configuration directives. These tags are really just shortcuts. You could use either of the following to publish a link to the image photo.jpg in your theme, for example:

<mt:StaticWebPath>support/plugins/MyPlugin/images/photo.jpg
<mt:MyPluginStaticWebPath>images/photo.jpg

both of which would output

http://example.com/mt/mt-static/support/plugins/MyPlugin/images/photo.jpg

Callbacks

Config Assistant supports a number of callbacks to give developers the ability to respond to specific change events for options at a theme and plugin level. All of these callbacks are in the options_change callback family.

On Single Option Change

Config Assistant defines a callback which can be triggered when a specific theme option changes value or when any theme option changes value. To register a callback for a specific theme option, you would use the following syntax:

callbacks:
  options_change.option.<option_id>: $MyPlugin::MyPlugin::handler

To register a callback to be triggered when any theme option changes, you would use this syntax:

callbacks:
  options_change.option.*: $MyPlugin::MyPlugin::handler

When the callback is invoked, it will be invoked with the following input parameters:

• $app - A reference to the MT::App instance currently in-context.
• $option_hash - A reference to a hash containing the name/value pairs representing this modified theme option in the registry.
• $old_value - The value of the option prior to being modified.
• $new_value - The value of the option after being modified.

Example

sub my_handler {
  my ($app, $option, $old, $new) = @_;
  MT->log({ message => "Changing " . $option->label . " from $old to $new." });
}

Note: The callback is invoked after the new value has been inserted into the config hash, but prior to the hash being saved. This gives developers the opportunity to change the value of the config value one last time before being committed to the database.

On Plugin Option Change

Config Assistat has the ability to trigger a callback when any option within a plugin changes. To register a callback of this nature you would use the following syntax:

callbacks:
  options_change.plugin.<plugin_id>: $MyPlugin::MyPlugin::handler

When the callback is invoked, it will be invoked with the following input parameters:

• $app - A reference to the MT::App instance currently in-context.
• $plugin - A reference to the plugin object that was changed

Sample config.yaml

id: MyPluginID
name: My Plugin
version: 1.0
schema_version: 1
static_version: 1
blog_config_template: '<mt:PluginConfigForm id="MyPluginID">'
plugin_config:
    MyPluginID:
        fieldset_1:
            label: "This is a label for my fieldset"
            hint: "This is some text to display below my fieldset label"
            feedburner_id:
                type: text
                label: "Feedburner ID"
                hint: "This is the name of your Feedburner feed."
                tag: 'MyPluginFeedburnerID'
skip_static:
    - index.html
    - readme.txt
    - .psd
    - .zip

In a follow up post to my attempt at explaining the GPL, it has become clear that there is one more very important thing that can still trip users up in trying to understand the GPL; and that is the difference between the software's license, and its copyright. These two concepts are often conflated, because in some respects they are related, but they have very different meanings, and convey very different rights to the people that hold them.

Copyrights and licenses are similar in that they both convey, or give specific rights to the people that hold them. Copyrights can only to be held by the people who create something, or to quote Wikipedia:

Copyright is the set of exclusive rights granted to the author or creator of an original work, including the right to copy, distribute and adapt the work.

A license on the other hand, encapsulates the rights and privileges that a copyright holder grants to someone else vis a vis something they have created. In the world of software the license defines the terms and conditions of someone else's usage of that software, and their rights with regards to their ability to copy and redistribute that software.

Let's look at some simple examples:

• Let's say I create a piece of software. If I chose to make that software available to others, than I should construct a license that defines for the people I give the software to what it is they can and cannot do with that software. While silly, granted, I could for example tell all the people I give the software to that they cannot use the software on Tuesdays and Thursdays. This is completely arbitrary obviously, but as the copyright holder of the software, that is my right.

• Let's say I create another piece of software, but instead of writing my own license, I turn to the Internet to help furnish a license for me. Why would I do this? Probably because I don't have the expertise to necessarily think of all the loop holes one of my customers might exploit to give away my software to others, or to potentially harm my business by suing me. So I find the template of a pretty standard software license, fill in the blanks, and use that. Done and done.

Alternatively, I could search the Internet and stumble across another license I am free to use with my software. This license is called the "GPL." It conveys a very different set of rights and privileges to the folks who download my software, but hey, the terms of the license suit me, so let's use that.

The Importance of Copyright in Open Source Software

Copyrights in open source software can add a new dimension of confusion, because in open source software where lots of different, unrelated people are collaborating to build something, it is quite possible that a single piece of open source software will have multiple copyright holders. Why is this significant?

Well, let's suppose that piece of software I wrote up above, you know the one that I licensed under the GPL? Well let's suppose it over the years two folks contributed heavily to the software: Jane and Susan. For the pieces they have written and contributed back to the software, they own the copyright. So now, the software that I created originally, is now in effect, jointly owned by me, Jane and Susan.

Then one day, out of the blue, I get a call from someone and they say: "Listen, I love your software and want to use it for my business. I am willing to pay you $1,000,000 for you to support my usage of the software, but I my company does not like GPL. Can you grant me a different license than the GPL?"

Holy moly that is a lot of money. Of course I want to say, "yes, yes, yes!" But I cannot change the terms under which I distribute the software unless I get the permission of every copyright holder. Jane and Susan may not mind changing the terms under which their contributions are redistributed, but they might also want to share in that $1,000,000. Heck, I would too if I were them. And that is just something I would have to work out with my fellow copyright holders if I wanted to see any of that $1,000,000.

Now in this example, relicensing the software is a very tractable possibility because the number of copyright holders is so finite. But for a piece of software like WordPress, this would be a virtually impossible proposition, because in order to change the license of WordPress, one would have to obtain the consent of virtually every single contributor WordPress has known. And if one person says, "no," then you are S.O.L.

This is why software organizations (like the Free Software Foundation) and companies (like Six Apart) who manage open source software require every contributor to assign the copyright of their creation back to them. That way there remains a single copyright holder thereby making future licensing decisions very easy to make and execute.

Copyright vs. Ownership

One final note. While writing this I found myself using the term "ownership" as a direct synonym to copyright. But I stopped myself because I realized that doing so might further confuse people as the term "ownership" will often imply a different set of rights. Consider this:

When I go to Best Buy and purchase a copy of Avatar on DVD, what do I actually own as a result? What I own is a physical disc and the right (or license) to watch its contents for my personal entertainment. All other uses are strictly prohibited.

In a certain number of years however, the copyright for Avatar will expire, and my rights vis-a-vis the DVD's contents will greatly expand. Once copyrighted material passes into the public domain, one is immediately free to copy, mix, re-mix, perform, and do what ever they want with it.

The DVD itself, the physical medium on which the movie is transmitted, would still be mine, exclusively; and the movie itself would still be owned by Twentieth Century Fox, but they would no longer exclusively possess the right to dictate to me (and others) how, when and under what circumstances that movie could be copied, performed and distributed. In this way ownership is perpetual, and copyright is not.

Summary

Hopefully, for the people who have stumbled across this blog post, this has helped you better understand some of the nuances between copyright and and software licenses. Please keep in mind though, that while I consider myself to be reasonably informed on these subjects, I am not a lawyer.

This blog post is owned by Byrne Reese and licensed under the Create Commons.

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.

To my Movable Type fans and followers, I apologize for not posting here more frequently about Movable Type. You will find that I have moved a lot of my Movable Type blogging to two places:

• Endevver's Blog - where I work
• Melody's Blog - where I play

My most recent post however is one that I feel warrants being cross posted, because it is news I am particular excited about. From the blog post on Melody:

A couple of weeks ago I posted my thoughts on creating a new packaging format for Melody plugins and its advantages:

The biggest advantage to [this new packaging format] is to allow us to use github to automate plugin and theme installation and upgrades because now one could easily do this: (snip)

What I am snipping out of the above quote are some geeky command lines which illustrate how to checkout a project from git. Such command line snippets now seem anachronistic given that the community has taken a major step in implementing this vision through a new plugin which, after a little TLC, will find its way right into Melody.

What is most exciting I think is the path and roadmap this plugin squarely puts us on. From the plugin's README:

This plugin is part of a larger effort to completely overhaul how plugins are discovered, installed and managed in Movable Type and Melody. The roadmap for this plugin is for it to interface directly with a centralized plugin directory managed by the community. In this capacity, the need to enter a git url at all will be completely obviated. Instead, users will search for the plugin they want from within Melody, and then click "install." The directory will know the git URL so users don't have to.

I have a love/hate relationship with Amazon right now as they recently made changes to their Amazon Product Advertising API that has broken Media Manager. Now I have numerous users tapping their feet anxiously waiting for an update, during a time in which I really should be working. I have only myself to blame though as Amazon gave me more than enough warning of this change, emailed me numerous times warning me about it, and honestly did all that a services provider should do to inform me of this impending change and its consequences. But naturally I procrastinated, and now I must reap what I sow.

On the flip side, this change has forced me to crack open one of my oldest plugins, one built with a great deal of duct tape and chicken wire, and retool it to be slightly more modern. Most users of course won't appreciate or notice a change, but I myself am relieved to finally replace all of my home-grown web services code, with a more stable and tested equivalent. This hopefully will make it easier for me to add features in the future and not cringe quite as much whenever a user reports a bug.

So while I privately curse Amazon under my breath, Media Manager and Movable Type users can thank Amazon for forcing me to finally devote some time to this plugin.

And that's the good news: Media Manager is getting a much needed overhaul: it is being updated to work with Amazon's new API restoring its operability; and I am making this work available for download today. The bad news is that this work is not 100% complete, so I must beg the for the community's continued patience and understanding in that this overhaul will take a little more time to complete. In the meantime, those willing to experiment with something that is partially complete, you can download and follow my progress with Media Manager over at github, and you can report bugs via the web and email over at Lighthouse.

As my life has been slowly re-attaining equilibrium after having a second child, I have still somehow managed to find time to make things. Thank god, because making things keeps me sane when life wants to dog pile my schedule, and my personal, professional and family life. Of course I have never really stopped making things, I have only struggled to find the time to tell people about the things I have made.

So today I break the silence and begin to catch you up with some of the many things I have made recently. The first thing I want to tell you about is a new tool I am especially proud of: Image Cropper.

Image Cropper is a plugin, sponsored by Talking Points Memo (an Endevver client) and donated to the Melody and Movable Type open source community, that helps bloggers compose and craft the images used on a web site to promote their content and stories. Of course Movable Type and Melody both possess the ability to do this today natively, but the difference between an amateur and a professional blog like Talking Points Memo, is the time and care they put into the polish they put into every single blog post. TPM for example employs producers to create these images and thumbnails manually because Movable Type's default behavior is ultimately insufficient. To see what I mean, let's look at a quick example.

Suppose we are composing a story about a visit between Barack Obama and Nicolas Sarkozy and we have the following photograph to accompany the story:

One thing you may notice about the photo is that the primary subjects of the photo are not centered in the photograph. This poses a problem because the thumbnail Movable Type will create for you automatically will crop out one or more of the primary subjects from the photo. Furthermore, at such a small size, the thumbnail created makes it difficult to determine who the primary subjects even are. This is why Talking Points Memo relied on a manual process to create these thumbnails so that they could produce the best possible result for their readers. Enter Image Cropper.

With Image Cropper we can override the default thumbnail and specify our own to produce an undeniably better result -- all from within Movable Type.

Furthermore, Image Cropper allows you to fine tune the file size and image quality of the image generated as well as annotate the image with text so that you can attach a photo credit or by-line.

To show you how easy it is to create results like this, here is a quick demonstration of the plugin in action:

To learn more about the plugin and to download it, visit the plugin's homepage over at Endevver. And if you need my help with a project, send us a note.

Hats off the WordPress community and Matt Mullenweg's insistence to promote open source design. Thanks to his philosophy and the courage of designers from the WordPress community, I am able to bring the Hybrid News Theme to Movable Type.

The Hybrid News Theme is the first newspaper theme for the Movable Type platform and enabled users to easily create a newspaper style web site:

If you are looking for the Hybrid News theme for WordPress, please visit their website.

Live Demo

View the live demo.

Download the Beta

This theme requires Movable Type Pro at is relies on custom fields for many of its advanced features.

• Download the latest

Bug Reports

This is beta software and is constantly being improved. Please submit bug reports at the following web site:

• Lighthouse Hybrid News Project
• Or submit them via email, making sure to use a descriptive subject header.

Installation

This plugin requires Movable Type Pro. It does not yet work with Movable Type Open Source. It is certainly my intent to support MTOS and Melody, just not at this time.

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

You will also need to install the following plugins:

• Config Assistant 1.01.
• Custom CSS
• Order 1.0
• Image Cropper 1.0

Features

• SEO enhanced:
  • Alternate HTML