PluginManager

[MightyMCoder]

This PR introduces the new Plugin Manager for Admidio.
It provides a simple user interface and standardized procedures for

• installing,
• uninstalling,
• updating,
• managing and
• integrating
  plugins in Admidio.

For more informations see the PluginManager-Wikipage.

closes #735 , closes #541, closes #1643, closes #1819

[github-actions]

WARNING: Unused translation keys detected

ORG_ACCESS_TO_PLUGIN
ORG_ACCESS_TO_PLUGIN_DESC
SYS_PLUGIN_DISABLED

Please consider removing or using these keys.

[MightyMCoder]

WARNING: Unused translation keys detected

ORG_ACCESS_TO_PLUGIN
ORG_ACCESS_TO_PLUGIN_DESC
SYS_PLUGIN_DISABLED

Please consider removing or using these keys.

These are false positives. The keys are used in the overview plugin json-Files.
@Fasse: We need to update the script file for this.

[github-actions]

WARNING: Unused translation keys detected

SYS_PLUGIN_DISABLED

Please consider removing or using these keys.

[MightyMCoder]

WARNING: Unused translation keys detected

SYS_PLUGIN_DISABLED

Please consider removing or using these keys.

This translation key is correctly detected as unused. I just implemented it for later usage.

[kainhofer]

Thanks, that's a great new feature for Admidio, which has been missing for quite some time!

A few ideas for improvement, though:

• In the plugin list, mark enabled/disabled plugins differently
• In the plugin list, allow one-click enable/disable of a plugin
• If there is an empty directory in the plugins/ directory, I get tons of errors:

Now that a plugin system is in place, I guess I'll try to spend some more time on the hooks/actions implementation (#1899, which is only a proof-of-concept with AI-generated code, but not polished code ready for inclusion), which would allow easy Wordpress-style customization of the inner workings of admidio. That would allow tweaking or extending admidio without modifying the core code (e..g the user change notifications could then be moved out from the core code to a simple plugin that registers some hooks whenever a user or database entry is changes. These hooks would then send the notification mails, and the core code can stick to the basics. Similarly, one could easily adjust headings, page appearances, etc.). Plugins registering such hooks would not need any classes, just the hook functions and their registration in the main plugin .php file.

[MightyMCoder]

@kainhofer:
Thanks for this fast feedback.
It looks like I missed some error handling when scanning for available plugins. I never tested what happens if the necessary folders or expected files are missing.
Could you please create an Issue for that?

Currently there is no disabling functionality because for me it was not clear how to realize it.
It would be easy for the admidio overview plugins but what is about 3rd party plugins?

In my opinion in this state of implementation it's enough to have the disable functionality through the settings if provided by the plugin itself.

[kainhofer]

About the disable functionality: Once there is a public plugin system in place with plugins that are not distributed together with the core, you always have to assume that there are plugins that will break the whole system (e.g. outdated code, bad coding, etc.). In that case, the plugin system needs to disable the plugin to allow admidio to function.

[MightyMCoder]

Now that a plugin system is in place, I guess I'll try to spend some more time on the hooks/actions implementation (#1899, which is only a proof-of-concept with AI-generated code, but not polished code ready for inclusion), which would allow easy Wordpress-style customization of the inner workings of admidio. That would allow tweaking or extending admidio without modifying the core code (e..g the user change notifications could then be moved out from the core code to a simple plugin that registers some hooks whenever a user or database entry is changes. These hooks would then send the notification mails, and the core code can stick to the basics. Similarly, one could easily adjust headings, page appearances, etc.). Plugins registering such hooks would not need any classes, just the hook functions and their registration in the main plugin .php file.

@kainhofer:
Yesterday I missed telling you that even a plugin which only implements hooks or just displaying things needs a least a main plugin class extending the PluginAbstract interface. Without this class there is no chance the plugin manager is able to list it as a plugin, managing settings or later implement update mechanisms for the plugin.
Please take a look to the references PluginManager-Wikipage adressing some necessary implemenations.