Not a developer? Go to


Your Plugin Module

When we discussed “The Basic Structure of a Plugin” we talked about Perl library files that reside in your /path/to/mt/plugins/Good4Nothing/lib directory. These “library files” are the source code of your plugin.

Most simple plugins have only one library file which adheres to this basic naming and packaging convention:


However, technically this is just convention. Plugins can and do deviate from this and so can yours.

Let’s begin:

  1. Create a directory called:


  2. In that directory create a file called and open it in a text editor

  3. Add the following text to your file:

    # Good for Nothing Plugin for Movable Type
    # Author: Your Name Here,
    # Copyright (C) 2008 Your Name Here
    # This file is licensed under the Artistic License, or the same
    # terms as Perl itself.
    package Good4Nothing::Plugin;
    use strict;
    sub tag {
        my ($ctx) = @_;
        my $cfg = $ctx->{config};
        return $cfg->MyImageURL;    
    1; # Every module must return true

The first 5 lines are boiler plate. Every Perl module and every source code file should include:

  • a brief description of what the file does
  • a copyright notice
  • the name of the author
  • the license under which the source code is made available.

For brevity’s sake, subsequent examples will omit this boiler plate code.

The next two lines define the name of the module, “Good4Nothing::Plugin” and signal to Perl to be more stringent in the syntax it will allow (‘use strict’). This is a good thing as it will allow Perl to help enforce in your code better coding practices by surfacing warnings you really should work to eliminate. As a general principle: no program, regardless of language, should issue warnings.

Building plugins to work with a specific version of Movable Type

When a plugin has been authored against a specific major version of Movable Type (e.g. MT 4.x, MT 5.x, MT 6.x etc), then it is recommended that your file also include the line:

use MT 4;

This signals to Movable Type what version of the internal plugin API is being used allowing Movable Type to adapt more readily to any backwards compatibility issues that may exist between your plugin and the current version of Movable Type.