!
Hubzilla DevelopmentMaybe someone smarter than me can help figure this out.
When an addon is added to Hubzilla (i.e., enabled by the hub admin), it runs the install functions, then the load functions. Typically, the load functions contain hook registrations.
However, the hook registrations, Hook::register(), only add the hook to the database. It does not add the hook to the internal App::$hook[] array for that "run-through". The problem is, if the "loading" relies upon some of those hooks as part of it's continued operation they won't get triggered during loading. (I didn't look, but from memory, I think the same problem exists during "unloading" and hook removal).
One thought was to simply run a Hook::insert() as part of the Hook::register() function. If you look at the commit log for dev, you'll see I did that, but almost immediately reverted it when I realized that because of the way that addons are unloaded and reloaded periodically, there is a possibility to have a hook read from the database and then duplicated via hook::insert() during the addon_load() procedure with little to no way to predict that it would be duplicated.
Also, in looking at this, I noted that "inserted" hooks are not prioritized when they are called but are merely appended to the list for the particular hook. This could introduce a number of unpredictable/unexpected problems for addon devs.
I'm not yet confident with my knowledge of the codebase to be sure that I catch all the places it may impact to do an overhaul of the hook functions. But my thought would be to change from using
App::$hooks[$name][] = array($file, $fn, $priority, $version);
to using something like
App::$hooks[$name][$priority][$fn] = array ($file,$fn,$priority,$version);
. This would automatically prioritize inserted hooks and automatically eliminate the possibility of (unintended) duplication. One problem I see is that it would also invert the current prioritization of hooks - as currently, hooks with a higher number as "priority" get run first.
Needless to say, there are a lot of pitfalls here - thus the reason I'm looking for people smarter than me.
@
Mike Macgirvin @
Mario Vavti @
Andrew Manning