Plugin Manager

[MightyMCoder]

There should be a standardized way of integrating plugins in Admidio.

Tasks of the Manager:

• Scan the plugin folder for all plugins placed there
• Get the plugin informations (name, description, version, author, preferences, ...) from a config file (JSON)
• Display status of plugin (installed, not installed, update available)
• Install, update or uninstall a plugin
• Point to preference panel of the plugin to change settings
• Check plugin dependencies before installing
• Implement a Overview Page preference panel where the arrangement of the overview plugins can be changed

Therefore all plugins should met some requirements:

• Each plugin has to provide a config file (JSON)
• if necessary new tables of the database must be specified in a separated db.sql file for installation
• If the plugin becomes a new version and update steps has to be performed these should be provided in a update_Vx_x.xml file (like for Admidio)

@Fasse: If you have more suggestions please feel free to add them.

I want to use this issue to keep track of all tasks.

---

mentioned by kainhofer:

• need proper interfaces into the settings

[kainhofer]

Regarding an extension system, the issue goes further than this request, which is only about the administration of plugins. The plugins

• need proper interfaces into the settings,
• the core code needs to be restructured, so that modules can live in their own directory rather than being scattered over the whole codebase (DB inside the db.sql, updater in update_*.xml, Presenters in src/UI/Presenter, code in modules/MODULENAME/, entities and services in src/MODULENAME/{Entity,Service}, translations in languages/, Smarty templates in themes/simple/...).
• Translations need to be handled properly.
• If a plugin crashes (e.g. because some core code changed in an incompatible way, or just due to a but in the extension), it should not bring down Admidio, but should be disabled (temporarily?).

Some of these things are touched by #541, but to me the largest thing to decide and design is the plugin interface API, i.e. how third-party extensions can hook into core functionality. Basically, there are three approaches:

• Plugins can replace any class in the whole codebase (Magento uses this system), which is very powerful, but in Magento's case makes it really hard to develop and maintain. Basically, the code in an extension has the same importance than the core code. Magento achieves this by merging the core and extension XMLs descriptions into one large database, which is used to resolve classes and functions/methods.
• Add event dispatchers and have extensions listen to certain pre-defined triggers. Joomla uses this approach. This allows plugins to react to certain actions (e.g. a SCIM client plugin could listen to all user/profile changes/additions/deletions and update the user base of the SCIM server app), but it does not allow modifying core functionality.
• Pipe objects (core object, or even HTML output before writing it to the client connection) through hooks that need to return the modified or unmodified object. This is what makes WordPress so successful. You can hook into almost all stages and modify the data structures before or after handling by the core code. Of course, this also gives devs the chance to bring down an installation easily or introduce hard-to-detect issues that appear to come from other plugins, but are actually caused by some rogue hook function.

[kainhofer]

Oh, and there should be an extension store on the Admidio server, so devs can provide their plugins easily.

[MightyMCoder]

Thanks a lot for your detailed input. That's very helpful!

I agree that designing a proper plugin interface API is key. The three approaches you described (class replacement, event dispatchers, and hooks) all sound interesting. Since I’m not very familiar with the pros and cons of each approach yet I’ll need to dive deeper into the topic before I can contribute to that part of the discussion.

I also agree with the idea of isolating plugin code. Having each plugin standardized and self-contained (including DB schema, services, translations, etc.) would definitely improve maintainability and reduce coupling.

The plugin manager is a major architectural change and will need to be implemented in steps.
Before we start with implementation we first need to define and agree on the basic structure and design principles of the new plugin system.

Once that foundation is in place I think the first concrete step should be to convert only the base plugins used on the overview page.
This allows us to test and refine the structure on a limited scope before expanding further.

Also I want to mention that this is too big to handle alone. I would definitely appreciate support from both of you especially in the early phase when it comes to implementing the basic structure and the first concrete steps.

[Fasse]

@kainhofer You are right, a proper plugin interface would be great. But I think we should focus at plugins at the first step. If that work nice than we can think about a restructure of the Admidio Core code which is definitly something for version 6.

If we implement a plugin interface step by step with focus on our own plugins, than this could be process within version 5, 5.1, 5.2 ...

If implementing a plugin interface we should always try to allow the current integration, so that current external plugins still work and must not converted.