Plugin Best Practices

From MovableType

Contents

Plugin Development Best Practices

This page is where we can list best practices for developers of MovableType plugins. It would be especially helpful if those of you who've made MT plugins could throw in suggestions based on areas where you had to make tough decisions.

General

  • Reuse existing Movable Type functionality as much as possible.
  • Require as few external dependencies as possible.
  • As much as possible, support the platforms, web servers, databases, and publishing environments that Movable Type supports.
  • If an existing plugin performs the same task as the plugin you intend to create, contact the Professional Network to see if the efforts can be combined.
  • Support APIs (listed below) and existing application-level callbacks where appropriate.

Using Movable Type's interfaces

Extensions and customizations should use the following interfaces, in order of preference, based on which interface exposes the appropriate and necessary functionality:

  1. Public, documented AtomAPI calls
  2. Public, documented XML-RPC Metaweblog API calls
  3. Smarty PHP plugins or Perl template plugins for template tags
  4. Text Filter plugins for transforming post content
  5. The documented Perl API for application-integrated plugins
    • Plugin actions
    • Application-level callbacks
    • Object-level callbacks
  6. Modifications to the CSS for the application
  7. Modifications to HTML templates for the application
  8. Modifications to Perl code in the application
  9. Modifications to CPAN modules which MT depends on

Display and Configuration

  • Do not name your plugin "MT-pluginname", instead use "plugin name" by itself
  • Expose your plugin in the Movable Type interface
  • Offer a working link to documentation in the application interface
  • Offer a configuration screen for user-configurable data. If you have no user-configurable data, the configuration screen can display plugin status.
  • Always register your plugin with MT so that users can determine whether your plugins has been successfully installed
  • Wrap use Perl::Mod statements in an eval and trap errors resulting from missing dependencies. Then display to your users clear messages indicating what prerequisites are not satisfied.

Documentation

  • Documentation should be shipped with the plugin so that users access documentation relevant to the version of the plugin they are using
  • Always ship your plugin with a README.txt file (better yet, call it README)
  • Always ship your plugin with an INSTALL.txt file (better yet, INSTALL!)
  • If your plugin uses a text file for configuration, then make sure it is well documented. For each paramter: indicate all default values, all allowable values, etc. mt.cfg is a good example

Installation

  • All necessary files should be shipped within a single directory and be dropped into MT_HOME/plugins to make installation as simple as possible
  • Provide tar and zip versions of your plugin

User Data

  • Default to not modifying user data within the database.
  • Obey Movable Type's security model for choosing which information your plugin user has access to.

Privacy and Security

  • Don't ever publish user login name, and don't access the stored password hash.
  • Default to moderating or not displaying visitor-contributed data.
Retrieved from "http://wiki.movabletype.org/Plugin_Best_Practices"