eis_os
-
Posts
5 -
Joined
-
Last visited
Posts posted by eis_os
-
-
Sorry, you get this wrong, this could be a start for a "proper" patch. Nothing that should be used out of the box in it's current form as the events currently leak to much of the "internal" State of Froxlor. (Specially the Cron Task IDs).
-
Hello
Maybe still useful for someone:
-edit-
(Don't use it in current form, only as source for ideas)
-/edit-
https://github.com/eis-os/Froxlor/tree/plugin-system- Hook System
- Plugin System
- Install / Update System for Plugins (easier to track changes)
- Settings Wrapper
Events are globally defined in /lib/classes/event/class.FroxlorEventConstants.php (only some are defined yet)
FroxlerEvent is the static class as glue between Froxlor and Froxlor Plugins.
A plugin extends /lib/classes/plugins/abstract.FroxlorPlugin.php,
internally it does automatically setup the necessary event functions, load language files and so on...
Hook system
in External modules
Posted
Well you can use FroxlorEvent::fire('CustomEvent', $eventdata);
If one module depends on the other, they could theoretical use events (and if something is missing it simple won't get an answer).
I made a pull request for the current changes (rebased and updated to last release): https://github.com/Froxlor/Froxlor/pull/344
Do I think it's the right way? Depends. From the technical standpoint plugins can run on their own quite nicely.
when they need to interact with code in Froxlor there are lot technical problems with the current codebase.
I use the plugin system to create nssextrausers and autoconfiguration of thunderbird clients (adds a alias line to apache config), so nothing big yet.
For testing purpose I wrote a plug-in to manage additional let's encrypt certs database entries, to see if the code works for UI tasks.
Froxlor leaks to much state in global variables, the UI plugin code code currently gets tunnelled via admin_plugin.php and there are still to much hardcode dependencies, like for doing a redirect.