Jump to content
Froxlor Forum

Hook system

Tomasz Czauderna

Recommended Posts

I declare to working with some extra futures.

And i  will plan started in short time.

But i look Yet on froxlor. Maybe better start to make something based on hook system this will be better for many reasons 

  • Easiest implementation
  • Faster development
  • Plug-in system
  • All existest futures make be ported to this system

Benefits smallest files and core will be separated not every time all will be parsed if not enabled.

All sorce should be more readable


We can do something based on open source or make something simple to realise this element


What's Your's opinion about this

Link to comment
Share on other sites

We have had this idea before...basically, just putt something like "Hook::callHook('name')" at any position you want to implement a hook. then have a static Hook-class that searches (defined) paths for files providing the hook-function 'name' and run it. 

Link to comment
Share on other sites

  • 2 months later...



Maybe still useful for someone:


(Don't use it in current form, only as source for ideas)



  • 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...

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

  • 3 weeks later...

Think of the Magento Shop Event System. In some classes you'll find the Event Dispatcher, which dispatches a current event (say "customer_logged_in" (example, may not exist)) and with it, it'll ship the current context with it. (probably the class itself $this). 

The event dispatcher iterates through configurated plugins/modules/extensions (whatever name you want to use) and executes their logic.



- multiple extensions can use the hook/xclass/event

- ...



- first come, first serve. Second in line will get already altered data. (Magento will allow you to specify dependencies in your modules configuration so you may be loaded before/after module XY)

- ...

Link to comment
Share on other sites

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. :unsure:

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...