Introduction

The main goal of the plugin architecture is community building. For an Open Source project to achieve a large community from the technical point of view it is most essential to enable the community to build new functionality / new features in and for translate5 without needing to change the core engine of translate5. The reason for this is, that the core engine needs a lean, well-engineered architecture and high stability in order to be a stable and future-proof base for a large number of installations. With a flexible plugin architecture anyone in the community can develop and contribute the feature he/she wants to in the way he wants to without the need to coordinate it with the main development of translate5 or the development of other plugins.

Planned Features

• a plugin management and configuration GUI, which supports
  • plugin features callable by hand
  • plugin configuration
  • manage plugin dependencies / collisions
  • plugin installation by Install and Update Kit
• define a complete set of event hook-ins for plugins
• do a complete documentation to enable community to use plugins for feature development
• definition of a file structure of plugins
  • To avoid Zend old style "Bandwurm" class names, php namespaces should be used and implemented in our class loader (have a look how/if Zf2 could be used for this)

current preliminary stage of implementation and usage

The current state is not really capable to serve community building so far - but it is a preliminary stage and already shows first architectural patterns. It already can be used to activate certain features in certain installations and not in others. And to develop plugins independent from the core, as far as the core already provides the necessary events and functionality for this.

• Plugins hook into events in translate5 core
• creation of the directory application/modules/editor/Plugins
• each Plugin gets an own directory, and therefore one or more Bootstrap classes:
  • application/modules/editor/Plugins/ReadOnlyByMeta/BootstrapTypeA.php
  • application/modules/editor/Plugins/ReadOnlyByMeta/BootstrapTypeB.php
• the Resource Plugin "ZfExtended_Resource_PluginLoader" loads the Plugins which are configured in the runtimeOptions.plugins.active. Configuration means to add the whole Bootstrap class name to the config list "runtimeOptions.plugins.active".
• for further documentation see /library/ZfExtended/Plugin/plugins.md

Technical remarks for future plugin management development

• plugin deactivation should ensure, that plugin could not be deactivated while dependent workers are running
• for each plugin containing own SQL should exist a SQL file which revokes the installed SQL changes. This should be triggered on removing a plugin.