Not a developer? Go to MovableType.com

Documentation

What is a Movable Type Application

From the outside looking in, Movable Type appears to be a single and complex application. In truth, Movable Type is composed of multiple applications that act in concert with one another to produce a flexible and powerful publishing platform. Each application serves a dedicated purpose and can actually act on its own as a stand alone application, allowing for greater resource control and management - which is a technical way of saying that this allows Movable Type to scale like nobody’s business.

Here is a list of the various applications that comprise Movable Type:

  • atom - handles requests via the Atom Publishing Protocol
  • cms - the main Movable Type administrative interface
  • comments - manages incoming comments
  • feeds - Movable Type’s activity feeds
  • new_search - a search backend introduced with MT 4.2
  • notify - for processing blog subscriptions and notifications
  • search - the legacy (pre MT 4.2) search backend
  • tb - the TrackBack engine
  • upgrade - for managing automated Movable Type upgrades
  • wizard - the installation wizard
  • xmlrpc - the XML-RPC server

Each of the applications above, along with every Movable Type application, has a dedicated .cgi file for processing requests related to the application, and each application has defined within the registry its own set of methods (or “modes”), list actions, page actions and more. Each of these concepts we will cover in greater detail later on, but for now understand that each of these aspects controls what links, widgets, and HTML Movable Type renders to the screen for the user to interact with.

Extending vs Building Applications

As a developer you have the choice of building your own dedicated application, or to extend an existing application. Building your own application offers the benefits of modularity and portability; it is recommended for those instances in which your application manifest a relatively large feature set or requires a large amount of dedicated resources (like memory, disk space, or CPU).

More often than not, however, plugins will extend an existing application. This is by far the simplest approach to take when building a plugin, as most plugins seek to augment the core application by adding a new screen, or adding elements to an existing screen. Therefore, the examples in this guide relate to extending the core “cms” application, or the main Movable Type administrative interface, commonly accessed through mt.cgi.

Application CGI

Each dedicated application utilizes its own .cgi. A separate CGI file is provided to allow the entire application to easily be transported to a separate host or cluster to expand the capacity and reliability of Movable Type. Every .cgi follows a very simple pattern, shown below:

#!/usr/bin/perl -w

use strict;
use lib $ENV{MT_HOME} ? "$ENV{MT_HOME}/lib" : 'lib';
use MT::Bootstrap App => 'MT::App::CMS';

If you were to create your own dedicated application, you would cut and paste the above sample code into your own .cgi file and replace MT::App::CMS with the name of the Perl module you create that contains all of the handlers relating to your application. The MT::Bootstrap module is what enables Movable Type to dispatch web requests to your application module at the appropriate times.

Applications in the Registry

Now, let’s take a closer look at the structure of an application as it is defined within the registry. This is important because when extending an application you need to register additional registry elements within this predefined structure. Here is a sample config.yaml file that contains a stubbed out application with an id of my_app.

name: Example Plugin for Movable Type
id: Example
description: This plugin is an example plugin for Movable Type.
version: 1.0
applications:
    my_app:
        cgi_base:
        handler:
        methods:
        page_actions:
        list_actions:
        list_filters:
        search_apis:
        menus:
        widgets:
        blog_stats_tab:
        tags:
        import_formats:

Application Registry Properties

The following are each of the application registry keys shown in the sample above explained:

  • cgi_base - the file name (without the extension) of the .cgi file for this application (e.g. “mt” for mt.cgi)
  • handler - the package that contains all of the handlers for this application
  • methods - a set of methods/modes
  • page_actions - a set of page actions
  • list_actions - a set of list actions
  • list_filters - a set of quick filters
  • search_apis -
  • menus - menus and menu items registered by this app
  • widgets - a set of dashboard widgets available to choose from
  • blog_stats_tab - a set of tabs to be added to the stats widget on the dashboard
  • tags - template tags provided by this application
  • import_formats - import handlers for pulling in content from other platforms and formats
Back

Leave a Comment