This page in other versions: master
Plugins are extensions to the core of FusionForge, providing extra functionality without being tightly integrated within FusionForge proper. They are useful because they allow for independent development of third-party functionality, and they add flexibility to FusionForge as to what features are available on a particular installation.
As an example, it's been suggested to integrate a wiki application in FusionForge. It's a good idea and an interesting feature, but not one that everybody wants to use the same wiki engine. Thus, including it in the FusionForge code would piss off someone. Additionnally, there might be several competing implementations for such a wiki engine application. Choosing one among them would also piss off people. So it is made possible to have a system so that different implementations can exist and be installed separately.
How plugins work
It is expected that a plugin is just some new feature added to FusionForge, and not a change in the behaviour of existing features. A plugin should therefore only add files, not change existing ones. Whether these files be web pages, offline scripts, static documentation or else is not relevant.
Of course, some changes will have to be made to the core files, if only to add links to new web pages, for instance. These changes are acceptable, and will be discussed below. Here come the details about how the plugin system is implemented.
A plugin will be identified primarily by a string handle, which will be static across all installations of this plugin. It should be composed of lowercase letters only, because it's going to be used in table names and we don't want namespace conflicts. For instance, if the ACME company writes a time tracking tool plugin, the handle for that plugin could be acmetimetracker. When installed, the plugin will be assigned an integer identifier. This id might vary from site to site, and should not be depended upon.