Confluence plugin guide

Confluence’s plugin system lets users and developers customize and extend Confluence. A plugin is a bundle of code, resources and a special configuration file that can be dropped into a Confluence server to add new functionality, or change the behavior of existing features.

• Administrators can drop plugins into their Confluence server to add new functionality to the system.
• Developers can write plugins for their own Confluence server, or share plugins with other Confluence users.

Some parts of Confluence are implemented entirely as plugins – for example, all macros in Confluence 1.3 and later are written as plugins, even those included with the system.

Plugins and plugin modules

Every plugin is made up of one or more plugin modules. A single plugin may do many things, while a plugin module represents a single function of the plugin.

For example, a theme plugin will consist of a colour-scheme module to define the theme’s colors, a number of layout modules to define the site’s page layouts, and a theme module to combine those pieces together into a single theme.

Some plugins, such as the macro packs that come with Confluence, are just a collection of unrelated modules that just happen to be packaged together. Other plugins, such as theme plugins, have modules that work together to provide some orchestrated functionality.

Where plugins are stored

Category	Storage
Manually installed	database
Installed via repository	database
Bundled plugins	conf-home
System plugins	WEB-INF/lib

For example, the System plugins chart plugin or the Widget Connector plugin will store data in WEB-INF/lib. Similarly for advanced-formatting macros.

Where plugin run-time data is stored

There is no distinct requirement where a Confluence plugin’s run-time data is stored. It is depended on the particular implementation of each plugin. The most common storage location would be: database, BANDANA, conf-home or other.