[HookBundle] Hooks redesign and improvements

[Kaik]

This is about our hook system in general.

1. Additional provider specific settings for a binding (subscriber?)
2. Redesign of current Hooks UI

example: Dizkus module -> general settings - Hooks (hopefully it works ;)

From slack Yes, I thought about it, in general, these are just additional settings for a binding between subscriber and provider. We could have both sides covered, but in case of a subscriber side, there is not much to play with or at least I cannot see any. For a provider, it works really well and it is a missing bit in our hooks system. The way I have done it is really complex (nested collections of forms without entity and with, a complex data structure), but in the end, there are just two files, a FormType with setting fields and, a template for it - it can be rendered without a template as well. Of course, we have to keep in mind that these settings are meant to affect only own side, so subscriber (will not have/should not have) access to provider settings. There are additional things to consider one is that at some point there may be too many modules/areas to display at once on one page so we would have to start with ajax or multi-step forms in mind. So to edit particular binding settings first you need to go to the providing module select provider -> select subscriber module - select subscriber area and then display settings. We would have to redesign our hooks admin interface https://github.com/zikula/core/issues/3924 it is cumbersome anyway. Place where we would store configuration matters as well if we chose hooks runtime table where actual binding exists, each time binding is removed our settings are gone - this is not that good since we/I have used (removing) to deactivate hook just for a moment... so either we add additional active-inactive status for a binding or we will store those settings somewhere else for example in module_vars table.

[Kaik]

Ok so now I know having all that forms from all bindings is hitting php default max input field setting which is 1000 :) and it is not even its full potential so...

• it has to be ajax
• the whole structure I have already need to be optimized

It is basing on a tree of all possible bindings the way it is visualized it is to decide. Final binding is between module provider area event and module subscriber area event. I'm experimenting with multi subscriber area modules so news, for example, has areas like: news.ui_hooks.news. all events - default news.ui_hooks.mainmedia all events news.ui_hooks.mainmedia.display_preview <- only one event display news.ui_hooks.gallery all events news.ui_hooks.comments all events news.ui_hooks.comments_info <- only one event display news.ui_hooks.comments_last <- only one event display

We can have a provider, for example, diskus or gallery that is providing all process edit events for comments but display view event can be used to display hooked object info in other areas. Each provider has to provide general settings form for the area that is providing. It is saved in module vars 'hooks'

[Kaik]

I have in mind a few ways how to display the whole structure. The configuration will be used mostly on the provider side. The current way is messed up a bit. There are two distinct actions doing the same thing, one is dropping the other one is a checkbox. There are two different views as well. Because it is some sort of a tree I'm thinking more about displaying everything at once, apart from the actual settings form of course.

So actual connection - binding we care about is between provider and subscriber both are defined by areas. From the "provider" point of view, you only care about sub-areas and matching events, similarly from the subscriber point of view. From our perspective, we can have both so it depends on how one prefers to think about it. We might want to add a way to change the view - reload tree with different data.

Next step is the actual list so we can mark the first level by module name or provider data (icons title etc.. etc..). List by (providing or subscribing) module is a default choice, I'm thinking we might provide, a list based on actual provider it will promote hooks more.

Level 2 is a list of again modules/subscribers if we go for modules then we need to add additional step because one module can have more than one subscriber if we go for subscribers it can be a lot of them eventually - but this can all be partially loaded via ajax.

Each subscriber/area will have an on-off switch which will do the binding. Apart from that a settings button so we can call settings form, collect data for that binding and store it.

Where and for how long to store data is to debate. The easiest way is to store those preferences in module vars because it does not require additional DB changes. Hooks being dynamic means there is only one "id" reference that binding setting can be identified and it is actually pmodule-parea-smodule-sarea combination. Settings object - array - that will be serialized for storage may be big and in a situation where there is a lot of matching subscribers might exceed column size. Storing settings in a different place than actual binding table preserves settings when the binding is not "ON" which is very useful - sometimes you might want to disable hook ( remove actual binding ) for maintenance but you do not want to lose settings.

So there is a lot of things to consider.

[Guite]

The green sections ("settings for this area") could be hidden and dynamically shown using a modal I guess. Then the basic display would be much cleaner again.

[Kaik]

@Guite those green sections are hidden by default you need to click that small cog icon to expand the ("settings for this area"). On load it looks like a list where rows with green background are marking enabled hooks.

But it has to be done differently anyway because at the moment the whole tree is loaded and it hits php max input fields setting which is 1000... and since it is all saved as a single module variable it might hit db limit for that field as well.

So maybe it would be better to display this list not as a form but as a list and then invoke settings for area via ajax/modal as you are suggesting, and the save data as pmodule-parea-smodule-sarea module var.

[craigh]

honestly, the picture above is so complicated, I cannot even read it.

Was thinking about this today and thought that a simple grid with checkboxes would be sufficient and simple.

• The ❌ indicates a non-hookable connection.
• The ✔️ indicates a hooked connection
• [ ] <-- would appear in eligible connections

the JS would be much simpler.

[Kaik]

The problem with this is that there are no hook settings for a connection.

Above picture (my one) is really complicated I know... So Gallery module have 2 providers.

1. Gallery provider which adds gallery as a hook
2. Main media provider which adds leading image/main media just one

this is fully collapsed view

Each of those providers can have its settings and these settings can be global or per connection with areas. Areas are listed by owning module so this is how it looks like when connection settings are collapsed (green rows are hooked - hook is enabled for that area)

Then settings for this area. I have splitted those into display view and edit view settings...

Hopefully that is more descriptive and clear.

[Guite]

Closing as hooks are entirely gone as part of Zikula 4 slimming diet.