Plugins / Hooks Section in ACP

General discussion of development ideas and the approaches taken in the 3.x branch of phpBB. The next feature release of phpBB 3 will be 3.3/Proteus.
Forum rules
Please do not post support questions regarding installing, updating, or upgrading phpBB 3.1. If you need support for phpBB 3.1 please visit the 3.1.x Support Forum on phpbb.com.

If you have questions regarding writing extensions please post in Extension Writers Discussion to receive proper guidance from our staff and community.
Post Reply
rma-web
Registered User
Posts: 11
Joined: Sat Jan 16, 2010 1:27 am

Plugins / Hooks Section in ACP

Post by rma-web » Sun Aug 29, 2010 12:24 am

Would it be worthwhile to have a Plugin / Hooks manager section in the ACP similar to what is in Joomla? Where you can change the execution order of plugins that use the same hook or something along those lines?

Jhong
Registered User
Posts: 50
Joined: Tue Dec 26, 2006 3:28 pm

Re: Plugins / Hooks Section in ACP

Post by Jhong » Tue Aug 31, 2010 7:54 am

Should this be something end-user-controllable? Shouldn't it be down to mod authors to understand and control the priority of their code in the hook call hierarchy?

Imagine how difficult it would be writing a MOD if the user was allowed to control how individual functions would be executed --- nightmare!

In addition, given the large number of hooks that will potentially be in 3.1x, any UI for hook ordering would be incredibly daunting.

I was thinking that a repository with social tagging would be the way forward. If users find that one mod is incompatible with another, they can comment on the mod in the repository, or tag them as mutually incompatible. Mod authors would then be able to rectify the problem.

gn#36
Registered User
Posts: 8
Joined: Mon Aug 30, 2010 9:09 pm

Re: Plugins / Hooks Section in ACP

Post by gn#36 » Tue Aug 31, 2010 9:32 pm

If you leave this up to the mods then the question is rather: Will the Mod Author be able to foresee all possible other mods that use the same hook and position his mod correctly in the execution order for all of them to work? I think there should be some way of sorting the mods so that Mod A can be executed before Mod B on hook_foo if Mod A otherwise breaks the changes made by Mod B. On the other hand both Mods and Hooks should be planned robust enough to work in any execution order. User interaction should be necessary in few circumstances only (two mods changing the same thing).
This should in most cases be achievable by separating the "checking" and "executing" part of a hook. For example, if a hook is to alter the Process of Adding a User and possibly cancel that process or add additional data to other tables, one would first execute a hook responsible for checking, whether adding the user is permitted or not (one could even think of also changing the data, as long as nothing is commited to the database, this might however cause problems if two mods change the same thing differently) and only after the user has been added add the additional data to other tables.
It is done this way in Subversion repository hooks for example. Here, you also will find a hook executed before and after commit. Only the first will be able to deny the commit, the second however will send you an email afterwards (or replicate the data to another server or whatever).

Jhong
Registered User
Posts: 50
Joined: Tue Dec 26, 2006 3:28 pm

Re: Plugins / Hooks Section in ACP

Post by Jhong » Wed Sep 01, 2010 2:14 am

Yes, a mod author should have a fair idea if it is critical whether his action should come first or last, or somewhere in-between.

I don't think most end-users have the ability to debug mod conflicts to a level that would suggest modifying execution order.

Furthermore, the order incompatibility is going to be on a "per-hook basis", not a "per-mod basis".

It's already hard enough getting users to cough up enough information when they are reporting problems with MODs -- imagine how much more difficult it would be if they could specify mod order. So the people who should be doing the debugging (the mod authors) can't, because there are too many variables.

Another important point: If execution order of mods at particular hooks is a common problem, perhaps that hook should be re-designed to make it more extensible.

Finally, I think the people who would care and understand hook execution order would be able to understand and modify PHP in a mod's hook file. On the other hand, ACP options to do this would just confuse everyone else.

That's 5 strong reasons why I think this would be a bad idea.... there are probably more.

Post Reply