Special Requirements: Some plugins need certain Perl modules to be pre-installed on the host system. Plugins may also use other resources, like graphics, other modules, applications, and templates. You should be able to find detailed instructions in the plugin's documentation. Use the package manager of the server OS (yum, apt-get, rpm, etc) to install dependent libraries.

If available, install CPAN (Comprehensive Perl Archive Network) libraries with the OS package manager. For example, to install IO::Socket::SSL on Fedora/RedHat/CentOS, run yum install perl-IO-Socket-SSL. CPAN modules can also be installed natively, see TWiki:TWiki.HowToInstallCpanModules.

Enabling/Disabling Plugins

• Set VARCACHEPLUGIN_REFRESH = 24

To learn how this is done, use the TWiki:Plugins.VarCachePlugin documentation and Perl plugin code as a reference.

2. Use configure settings:

The administrator can set plugin settings in the configure interface. Recommended if only site administrators should be able to change settings. Chose this option to set sensitive or dangerous system settings, such as passwords or path to executables. To define plugin-specific configure settings,

• Create a Config.spec file in lib/TWiki/Plugins/YourPlugin/ with variables, such as
  $TWiki::cfg{Plugins}{RecentVisitorPlugin}{ShowIP} = 0;
• In the plugin, use those those variables, such as
  $showIP = $TWiki::cfg{Plugins}{RecentVisitorPlugin}{ShowIP} || 0;

To learn how this is done, use the TWiki:Plugins.RecentVisitorPlugin documentation and Perl plugin code as a reference.

In either case, define a SHORTDESCRIPTION setting in two places:

• As a setting in the plugin documentation, which is needed for the extension reports on twiki.org. Example:
  
  • Set SHORTDESCRIPTION = Show recent visitors to a TWiki site
• As a global Perl package variable in the plugin package, which is needed by TWiki to show info on installed plugins. Example:
  our $SHORTDESCRIPTION = 'Show recent visitors to a TWiki site';

For better performance, make sure you define this in the plugin package:
our $NO_PREFS_IN_TOPIC = 1;

• All but the initPlugin are commented out. To enable a callback, remove the leading # from all lines of the callback.

• Avoid using preferences in the plugin topic; Define $NO_PREFS_IN_TOPIC in your plugin package as that will stop TWiki from reading the plugin topic for every page. Use Config.spec or preferences settings instead. (See details).
• Use registered tag handlers.
• Measure the performance to see the difference.

• • In the JumpBox enter your plugin name, for example MyFirstPlugin, press enter and create the new topic

Note that from TWiki 5.0 onwards, CGI scripts (in the TWiki bin directory) provided by extensions must also have an entry in the Config.spec file. This entry looks like this (example taken from PublishContrib)

# **PERL H**
# Bin script registration - do not modify
$TWiki::cfg{SwitchBoard}{publish} = [ "TWiki::Contrib::Publish", "publish", { publishing => 1 } ];

• rapidly develop new TWiki functions in Perl using the plugin API.

Configure variables are accessible though the configure interface.

Plugin preferences variables are defined in the plugin topic and can be overloaded. The SHORTDESCRIPTION preferences variable is always present, it is needed for the TWiki:Plugins repository on twiki.org. Example preferences variable defined in the TablePlugin topic:

• Set SHORTDESCRIPTION = Control attributes of tables and sorting of table columns

Preferences variables of active plugins can be retrieved anywhere in TWiki with %<pluginname>_<var>%, such as %TABLEPLUGIN_SHORTDESCRIPTION%. They can also be redefined with the %<pluginname>_<var>% setting at a lower level in the Main.TWikiPreferences or at the web level. For an easier upgrade it is recommended to customize plugin preferences variables in Main.TWikiPreferences only.

• Delay initialization as late as possible. For example, if your plugin is a simple syntax processor, you might delay loading extra Perl modules until you actually see the syntax in the text.

• • The plugin initialization code does not register a plugin that returns 0 (or that has no initPlugin handler).

• $TWiki::Plugins::VERSION in the TWiki::Plugins module contains the TWiki plugin API version, currently 6.00.
  • You can also use the %PLUGINVERSION{}% variable to query the plugin API version or the version of installed plugins.

• Badly written plugins can open huge security holes in TWiki. This is especially true if care isn't taken to prevent execution of arbitrary commands on the server.
• Don't allow sensitive configuration data to be edited by users. it is better to add sensitive configuration options to the %TWiki::cfg hash than adding it as preferences in the plugin topic.
  • Integrating with configure describes the steps
  • TWiki:Plugins.MailInContrib has an example

• Always audit the plugins you install, and make sure you are happy with the level of security provided. While every effort is made to monitor plugin authors activities, at the end of the day they are uncontrolled user contributions.

1. Copy the plugin topic template from TWiki.org. To copy the text, go to TWiki:Plugins/PluginPackage and:
   • enter the plugin name in the "How to Create a Plugin" section

• • In the GoBox enter your plugin name, for example MyFirstPlugin, press enter and create the new topic
  • paste & save new plugin topic on your site

1. Customize your plugin topic.
   • Important: In case you plan to publish your plugin on TWiki.org, use Interwiki names for author names and links to TWiki.org topics, such as TWiki:Main/TWikiGuest. This is important because links should work properly in a plugin topic installed on any TWiki, not just on TWiki.org.

1. Save your topic, for use in packaging and publishing your plugin.

1. Distribute the plugin files in a directory structure that mirrors TWiki. If your plugin uses additional files, include them all:

1. Create a zip archive with the plugin name (MyFirstPlugin.zip) and add the entire directory structure from Step 1. The archive should look like this:

1. Post the plugin documentation topic in the TWiki:Plugins/PluginPackage:
   • enter the plugin name in the "How to Create a Plugin" section, for example MyFirstPlugin

1. Link from the doc page to a new, blank page named after the plugin, and ending in Dev, ex: MyFirstPluginDev. This is the discussion page for future development. (User support for plugins is handled in TWiki:Support.)
2. Put the plugin into the SVN repository, see TWiki:Plugins/ReadmeFirst (optional)

• Identify where the attachment originated from, typically by including the plugin name in the file name

• Example: _GaugePlugin_img123.gif

Tip:

TWiki:TWiki.TWikiPluginsSupplement#MaintainPlugins

    if( $TWiki::Plugins::VERSION >= 1.1 ) {
        @webs = TWiki::Func::getListOfWebs( 'user,public' );
    } else {
        @webs = TWiki::Func::getPublicWebList( );
    }

TWiki Plugins

• Keep the main plugin package as small as possible; create other packages that are loaded if and only if they are used. For example, create sub-packages of BathPlugin in lib/TWiki/Plugins/BathPlugin/.
• Avoid using preferences in the plugin topic; set $NO_PREFS_IN_TOPIC if you possibly can, as that will stop TWiki from reading the plugin topic for every page. Use Config.spec instead.
• Use registered tag handlers
• Measure the performance to see the difference

Version Detection

• All plugin packages require a $VERSION variable. This should be an integer, or a subversion version id.

• The initPlugin handler should check all dependencies and return 1 if the initialization is OK or 0 if something went wrong.
  • The Plugin initialization code does not register a Plugin that returns 0 (or that has no initPlugin handler).

• a Perl module, e.g. MyFirstPlugin.pm
• a documentation topic, e.g. MyFirstPlugin.txt

• • go back to your site to the TWiki web

• Plugins Preferences <If user settings are needed, explain... Entering values works exactly like TWikiPreferences and WebPreferences: six (6) spaces and then:>"

Measuring and Improving the Plugin Performance

A high quality Plugin performs well. You can use the TWiki:Plugins.PluginBenchmarkAddOn to measure your TWiki:Plugins.PluginBenchmarks. The data is needed as part of the Documentation Topic.

See also Hints on Writing Fast Plugins.

Integrating with configure

Config.spec files are read during TWiki configuration. Once a Config.spec has defined a configuration item, it is available for edit through the standard configure interface. Config.spec files are stored in the 'plugin directory' e.g. lib/TWiki/Plugins/BathPlugin/Config.spec.

Structure of a Config.spec file

# ---+ BathPlugin
# This plugin senses the level of water in your bath, and ensures the plug
# is not removed while the water is still warm.

# **SELECT Plastic,Rubber,Metal**
# Select the plug type
$TWiki::cfg{BathPlugin}{PlugType} = 'Plastic';

# **NUMBER**
# Enter the chain length in cm
$TWiki::cfg{BathPlugin}{ChainLength} = '30';

# **BOOLEAN EXPERT**
# Turn this option off to disable the water temperature alarm
$TWiki::cfg{BathPlugin}{TempSensorEnabled} = '1';

if( $TWiki::cfg{BathPlugin}{TempSensorEnabled} && $curTemperature > 50 ) {
    die "The bathwater is too hot for comfort";
}

The config.spec file is read by configure, and configure then writes LocalSite.cfg with the values chosen by the local site admin.

A range of types are available for use in Config.spec files:

All types can be followed by a comma-separated list of attributes.

See lib/TWiki.spec for many more examples.

Config.spec files are also used for other (non-plugin) extensions. in this case they are stored under the Contrib directory instead of the Plugins directory.

• TWiki:TWiki.TWikiPluginsSupplement - tip: supplemental documentation on TWiki plugins
• TWiki:Plugins.PluginPackage - list of all contributed plugin packages
• TWiki:Plugins.PluginDevelopment - discussion and feedback on contributed plugins
• TWiki:Plugins.PluginBrainstorming - open forum for new plugin ideas
• TWiki:Plugins.PluginPackageHowTo - template to create a new plugin package

See other types of extensions: TWikiAddOns, TWikiContribs, TWikiSkins

Define DISABLEDPLUGINS to be a comma-separated list of names of plugins to disable. Define it in Main.TWikiPreferences to disable those plugins everywhere, in the WebPreferences topic to disable them in an individual web, or in a topic to disable them in that topic. For example,

   * Set DISABLEDPLUGINS = SpreadSheetPlugin, EditTablePlugin

• Set SETTING = Create dynamic foo bar reports

• • You can also use the %PLUGINVERSION{}% variable to query the Plugin API version or the version of installed Plugins.

Special Requirements: Some Plugins need certain Perl modules to be preinstalled on the host system. Plugins may also use other resources, like graphics, other modules, applications, and templates. You should be able to find detailed instructions in the Plugin's documentation.

Some Notes on Plugin Performance

Managing Installed Plugins

Enabling Plugins

Plugin Evaluation Order

Plugin-Specific Settings

• • Set SHORTDESCRIPTION = Create dynamic foo bar reports

• The settings can be retrieved as Preferences variables like %<pluginname>_<var>%. For example, %DEFAULTPLUGIN_SHORTDESCRIPTION% shows the description of the DefaultPlugin.

%ACTIVATEDPLUGINS%

%PLUGINDESCRIPTIONS%

%FAILEDPLUGINS%

• Delay initialization as late as possible. For example, if your Plugin is a simple syntax processor, you might delay loading extra Perl modules until you actually see the syntax in the text.
• For example, use an eval block like this:
  

• The TWiki:Plugins.PluginBenchmarkAddOn comes in handy to measure and fine-tune the performance of your Plugin

• • You can also use the %PLUGINVERSION{}% variable to query the Plugin API version or the version of installed Plugins.

Security

• Badly written Plugins can open huge security holes in TWiki. This is especially true if care isn't taken to prevent execution of arbitrary commands on the server.
• Don't allow sensitive configuration data to be edited by users. it is better to add sensitive configuration options to the %TWiki::cfg hash than adding it as preferences in the Plugin topic
  • See TWiki:Plugins.MailInContrib for an example of this
  • TWiki:Plugins.BuildContrib can help you with this
• Always use the TWiki::Sandbox to execute commands.
• Always audit the Plugins you install, and make sure you are happy with the level of security provided. While every effort is made to monitor Plugin authors activities, at the end of the day they are uncontrolled user contributions.

Measuring and Improving the Plugin Performance

A high quality Plugin performs well. You can use the TWiki:Plugins.PluginBenchmarkAddOn to measure your TWiki:Plugins.PluginBenchmarks. The data is needed as part of the Documentation Topic.

See also Hints on Writing Fast Plugins.

1. Customize your Plugin topic.
   • Important: In case you plan to publish your Plugin on TWiki.org, use Interwiki names for author names and links to TWiki.org topics, such as TWiki:Main/TWikiGuest. This is important because links should work properly in a Plugin topic installed on any TWiki, not just on TWiki.org.
2. Document the performance data you gathered while measuring the performance
3. Save your topic, for use in packaging and publishing your Plugin.

TWiki:Plugins.BuildContrib

If you don't want (or can't) use the BuildContrib, then a minimum Plugin release consists of a Perl module with a WikiName that ends in Plugin, ex: MyFirstPlugin.pm, and a documentation page with the same name(MyFirstPlugin.txt).

1. Distribute the Plugin files in a directory structure that mirrors TWiki. If your Plugin uses additional files, include them all:

• • paste in the topic text from Writing the Documentation Topic and save

1. Put the Plugin into the SVN repository, see TWiki:Plugins/ReadmeFirst (optional)

Once you have done the above steps once, you can use the BuildContrib to upload updates to your Plugin.

Recommended Storage of Plugin Specific Data

Plugins sometimes need to store data. This can be Plugin internal data such as cache data, or data generated for browser consumption such as images. Plugins should store data using TWikiFuncDotPm functions that support saving and loading of topics and attachments.

Plugin Internal Data

You can create a Plugin "work area" using the TWiki::Func::getWorkArea() function, which gives you a persistant directory where you can store data files. By default they will not be web accessible. The directory is guaranteed to exist, and to be writable by the webserver user. For convenience, TWiki::Func::storeFile() and TWiki::Func::readFile() are provided to persistently store and retrieve simple data in this area.

Web Accessible Data

Topic-specific data such as generated images can be stored in the topics attachment area, which is web accessible. Use the TWiki::Func::saveAttachment() function to store the data.

Recommendation for file name:

• Prefix the filename with an underscore (the leading underscore avoids a nameclash with files attached to the same topic)
• Identify where the attachment originated from, typically by including the Plugin name in the file name
• Use only alphanumeric characters, underscores, dashes and periods to avoid platform dependency issues and URL issues
• Example: _FooBarPlugin_img123.gif

Web specific data can be stored in the Plugin's attachment area, which is web accessible. Use the TWiki::Func::saveAttachment() function to store the data.

Recommendation for file names in Plugin attachment area:

• Prefix the filename with an underscore
• Include the name of the web in the filename
• Use only alphanumeric characters, underscores, dashes and periods to avoid platform dependency issues and URL issues
• Example: _Main_roundedge-ul.gif

Maintaining Plugins

Discussions and Feedback on Plugins

Each published Plugin has a Plugin development topic on TWiki.org. Plugin development topics are named after your Plugin and end in Dev, such as MyFirstPluginDev. The Plugin development topic is a great resource to discuss feature enhancements and to get feedback from the TWiki community.

Maintaining Compatibility with Earlier TWiki Versions

The Plugin interface (TWikiFuncDotPm functions and handlers) evolve over time. TWiki 4.0 introduced new API functions to address the needs of Plugin authors. It also deprecated some functions. Some Plugins written for earlier TWiki releases using unofficial TWiki internal functions no longer work on the TWiki 4.0 codebase. All this means that some Plugins need to be updated to work on the TWiki 4.0 codebase.

Organizations typically do not upgrade to the latest TWiki for many months. However, many administrators still would like to install the latest versions of a Plugin on their older TWiki installation. This need is fullfilled if Plugins are maintained in a compatible manner.

Tip: Plugins can be written to be compatible with older and newer TWiki releases. This can be done also for Plugins using unofficial TWiki internal functions of an earlier release that no longer work on the latest TWiki codebase. TWiki:TWiki.TWikiPluginsSupplement#MaintainPlugins has more.

Handling deprecated functions

• $TWiki::Plugins::VERSION in the TWiki::Plugins module contains the TWiki Plugin API version, currently 6.00.
  • You can also use the %PLUGINVERSION{}% variable to query the Plugin API version or the version of installed Plugins.

• EmptyPlugin: Is a fully functional module, minus active code; it does nothing and serves as a template for new Plugin development
• CommentPlugin: %COMMENTPLUGIN_SHORTDESCRIPTION%
• InterwikiPlugin: Use it for shorthand linking to remote sites, ex: TWiki:Plugins expands to TWiki:Plugins on TWiki.org. You can edit the predefined set of of Wiki-related sites, and add your own

Checking that Plugins are Working on a Live Server

InstalledPlugins shows which Plugins are: 1) installed, 2) loading properly and 3) what TWiki:Codev.PluginHandlers they invoke. Any failures are shown in the Errors section.

1. Post the Plugin documentation topic in the TWiki:Plugins/PluginPackage:
   • enter the Plugin name in the "How to Create a Plugin" section, for example MyFirstPlugin

1. Put the Plugin into the CVS repository, see TWiki:Plugins/ReadmeFirst (optional)

Recommended Storage of Plugin Data

Plugins sometimes need to store data. This can be Plugin internal data like cache data, or generated data for the browser like images. The following is a recommendation where to store the data.

Where to store Plugin Internal Data

In case the Plugin generates data just for internal use, or data which is not specific to a topic, store it in the Plugin's attachment directory.

• The Plugin's attachment directory is pubdir/Installweb/FooBarPlugin
  • Installweb refers to the name of the web where the Plugin is installed
• The Plugin's attachment URL is %PUBURL%/Installweb/FooBarPlugin
• The filename should start with an underscore, followed by an identifier, e.g. _any_name.ext
  • The leading underscore avoids a nameclash with files attached to the Plugin topic
  • Use only alphanumeric characters, underscores and periods to avoid platform dependency issues and URL issues
  • Do not use subdirectories (rename and delete would fail)
• Use Plugin API functions documented in TWikiFuncModule to ensure portability:
  • Use getPubDir() to get the attachment root directory
  • Use getUrlHost() and getPubUrlPath() to build the URL in case you create content for the browser
  • Use $installWeb to get the name of the web where the Plugin is installed
  • Create the web directory and topic attachment directory if needed
• Hint: Package the Plugin at least with one file attachment. This ensures that the attachment directory already exists

Where to Store Data for Topics using the Plugin

In case the Plugin generates data which is specific to a topic, store it in the topic's attachment directory.

• The topic's attachment directory is pubdir/Webname/TopicName
• The topic's attachment URL is %PUBURL%/Webname/TopicName
• The filename should start with an underscore, followed by the Plugin name, an underscore and an identifier, e.g. _FooBarPlugin_any_name.ext
  • The leading underscore avoids a nameclash with files attached to the same topic
  • Use only alphanumeric characters, underscores and periods to avoid platform dependency issues and URL issues
  • Do not use subdirectories (rename and delete would fail)
• Use Plugin API functions documented in TWikiFuncModule to ensure portability:
  • Use getPubDir() to get the attachment root directory
  • Use getUrlHost() and getPubUrlPath() to build the URL in case you create content for the browser

Example code to build the file name:

sub _make_filename
{
    my ( $web, $topic, $name ) = @_;

    # Create web directory "pub/$web" if needed
    my $dir = TWiki::Func::getPubDir() . "/$web";
    unless( -e "$dir" ) {
        umask( 002 );
        mkdir( $dir, 0775 );
    }
    # Create topic directory "pub/$web/$topic" if needed
    $dir .= "/$topic";
    unless( -e "$dir" ) {
        umask( 002 );
        mkdir( $dir, 0775 );
    }
    return "$dir/_FooBarPlugin_$name";
}

-- TWiki:Main/PeterThoeny - 11 Dec 2003
-- TWiki:Main/AndreaSterbini - 29 May 2001
-- TWiki:Main/MikeMannix - 03 Dec 2001

• DefaultPlugin: Optionally handles some legacy variables from older versions of TWiki. You can control this option from TWikiPreferences. (Perl programmers can also add rules for simple custom processing.)
• EmptyPlugin: Is a fully functional module, minus active code; it does nothing and serves as a template for new Plugin development.
• InterwikiPlugin: Use it for shorthand linking to remote sites, ex: TWiki:Plugins expands to TWiki:Plugins on TWiki.org. You can edit the predefined set of of Wiki-related sites, and add your own.
• EditTablePlugin: Edit TWiki tables using edit fields, date pickers and drop down boxes
• RenderListPlugin: %RENDERLISTPLUGIN_SHORTDESCRIPTION%
• SlideShowPlugin: Create web based presentations based on topics with headings.
• SmiliesPlugin: Render smilies as icons, like  :-)  as or  :eek:  as
• SpreadSheetPlugin: Add spreadsheet calculation like "$SUM( $ABOVE() )" to TWiki tables or anywhere in topic text
• TablePlugin: Control attributes of tables and sorting of table columns

A Note on Plugin Performance

• commonTagsHandler: Use it to expand %XYZPLUGIN% and %XYZPLUGIN{...}% variables
• startRenderingHandler: Use it for your own rendering rules or to overload TWiki's internal rendering like [[links]]

TWiki:Codev/StepByStepRenderingOrder helps you decide which rendering handler to use.

Hints on Writing Fast Plugins

• Delay the Plugin initialization to the actual function which is handling the tag. This way all the expensive initialization is done only when needed.
• For example, use an eval block like:
  eval { require IPC::Run }
return "<font color=\"red\">SamplePlugin: Can't load required modules ($@)</font>" if $@;
• You could return errors as strings to show what happened
• You can use a flag to avoid running the initialization twice

A Note on Performance

The performance of the system depends on the number of Plugins installed and on the Plugin implementation. Some Plugins impose no measurable performance decrease, some do. For example, outsidePREHandler is an expensive callback function, or a Plugin might use many Perl libraries that needs to be initialized with each page view (unless you run mod_perl). It is recommended to measure the performance with and without a new Plugin.

In case you need to install an "expensive" Plugin and you need its functionality only in one web you can place the Plugin topic into that web. TWiki will initialize the Plugin only if the Plugin topic is found (which won't be the case for other webs.)

• • Duplicate the twiki/bin and twiki/lib directories for the Test version, and adjust the paths in the new lib/TWiki.cfg. The following directories are shared: twiki/data, twiki/templates and twiki/pub.

• For best performance, enable only the functions you really need. NOTE: outsidePREHandler and insidePREHandler are particularly expensive.

If your Plugin uses its own modules and objects, you must include the name of the Plugin in the package name. For example, write Package MyFirstPlugin::Attrs; instead of just Package Attrs;. Then call it using:

  use TWiki::Plugins::MyFirstPlugin::Attrs;
  $var = MyFirstPlugin::Attrs->new();

1. Copy the Plugin topic template from TWiki.org. To copy the text, go to TWiki:Plugins/PluginPackage and:
   • enter the Plugin name in the "How to Create a Plugin" section
   • click Create
   • select all in the Edit box & copy

• • go back to your site to the TWiki web
  • In the GoBox enter your Plugin name, for example MyFirstPlugin, press enter and create the new topic
  • paste & save new Plugin topic on your site

1. Customize your Plugin topic.
   • In case you plan to publish your Plugin at TWiki.org, use Interwiki names for author names, like TWiki:Main/TWikiGuest.
2. Save your topic, for use in packaging and publishing your Plugin.

• Plugins Preferences <If user settings are needed, explain... Entering values works exactly like TWikiPreferences and WebPreferences: six (6) spaces and then:>"
  • Set <EXAMPLE = value added>

• For best performance, enable only the functions you really need. NOTE: outsidePREHandler and insidePREHandler are particularly expensive.