Plugin architecture

[billz]

One idea I've played with is adding plugin support for RaspAP. This would let other developers build enhancements for the project without modifying the core code.

Examples include this interesting fork of RaspAP that adds RPiPlay integration. While this may not appeal to everyone, there are probably some users who would add this to RaspAP if it could be done simply.

There are several design patterns for a plugin system that could be used here. My personal take is to avoid frameworks and go with a minimal event dispatcher-type implementation.

Does a plugin system make sense for RaspAP?
If yes, which plugins would you like to see added?

[assachs]

Hello Billz,
i want to push this idea. Some rudimentary plugin support would be nice. This includes

• adding entries to the sidebar
• delegating page_actions to the plugin
• render templates from a plugin directory

I already implemented a first version of the plugin support.

My personal use case:
we use raspap on a DIY electronic scoreboard to connect the scoreboard to the wifi and also to configure the scoreboard (this is the plugin part)

At first i changed raspap and included the changes for the scoreboard. For the second version i added plugin support to raspap and moved the scoreboard functionality to the plugin. But it would be nice, if the plugin support is available in the original version and not only in my fork.

[billz]

Glad to see this and nicely done. I'll dust off my plugin fork and perhaps integrate some of the work you've already done.

[billz]

Currently in progress #1693. User plugins are auto-loaded from the /plugins folder by the PluginManager.

A priority value allows plugin sidebar items to be positioned arbitrarily:

I'll publish SamplePlugin in a separate repo shortly, once the template rendering and page action handling is done.

[assachs]

Your solution looks very nice. Thank you very much.

[billz]

@assachs your work provided some much needed inspiration. I will credit you in the code and release notes :)

[assachs]

@billz Hello Bill, i had no time to convert my plugin to the new plugin implementation (maybe tomorrow), but i already looked at the source code.

2 Ideas:

• Move handlePageAction to the Plugin-Class.
• The class autoloader should also use the pluginmanager and should load classes with the same namespace (or subdirectory) from the plugin-folder.

With this approach functions.php is not needed any more. One Namespace is sufficient (at the moment there is a namespace for functions.php and one for the Plugin).

For complex plugins the functions can be divided in several classes without the need of require_once

[billz]

@assachs thanks for the valuable feedback. I agree re: handlePageAction. Actually, I started coding this in the PluginManager and later implemented it again in the SamplePlugin, so arrived at this in a roundabout way. Encapsulating this at the plugin level is a better approach.

[billz]

Both the PluginManager and SamplePlugin are nearly code complete. The latter needs some usage notes in the README, although the code is reasonably well documented.

The PluginManager was tested with multiple plugin instances, each with their own data persistence.