Menu
▾
▴
#256 Provide hooks for modules
Quite a few modules (Protector and MetaTags come to mind) need to be able to hook into Xoops. This is usually done by the site owner having to hack into mainfile.php, footer.php or header.php.
It would be better if Xoops provided a mechanism whereby when a module installs, it can register itself as needing to hook into one of these files at an appropriate point.
Many years ago I worked on Burroughs CTOS machines and the OS for these was written as a set of vector offsets. This meant that you could insert new code into the OS simply by changing the vector table. This may be a way that could be used to run mainfile et al, or perhaps someone has a better solution.
At the very minimum we could provide two entry points into mainfile (beginning and end) and similarly for header and footer.php (although in footer's case it would need to be prior to the actuall page display.) At these points Xoops looks to a system table to see if it has any registered module code to run and runs it.
The real advantage of this is that it stops end users having to hack code and places the onus back on the module developer.
Logged In: YES
user_id=1031058
Originator: NO
Indeed it's a good idea and a recurrent discussion in XOOPS over the past years. It's true that modules needs to have hook functionnality to interact with the core but also with others modules.
Do you have ideas on the architecture to implement ?
Can you detail your suggestions and proposals ?
For such functionalities it's important to have a detail conception and a proof of concept.
Logged In: YES
user_id=700563
Originator: YES
@pemen
I'm not a core developer (I develop modules as you may be aware.) Do you want me to develop a patch like I did for the email checker? Problem with that is that I did that at phppp's request over a year ago and still it hasn't been incorporated into core. So before committing myself to the work I'd like some assurance from the core dev team that this is a good idea and that it will be accepted (subject to peer review, tweaking etc etc.)
Alternatively I can simply design it on paper and one of you guys can take it on to develop, but again I need the assurance that someone is willing to take it on.
The other major concern I have is that what I am proposing is a/ fairly modest in its aims and b/ would be based on the current 2.0.16 workstream. I have no idea where you guys are going to take Xoops beyond that. I had heard that a major re-engineering of the way the whole core works was being undertaken. I'd heard rumours of event handlers and a polymorphic kernel. Therefore anything done now would be scrapped going forward.
If you or anyone else can shed some light on what is likely to happen then I'll do my best.
BTW pemen - good job on the openid stuff. I look forward to seeing that in the core.
A
Logged In: YES
user_id=1384873
Originator: NO
@akitson
I am really very interested on the hook feature in the core, to improve the usability of xoops to the newbies xoopers, every one which dont have code skills maybe to implement a little hack in the mainfile.php footer.php or in the header.php, so i repeat that i am very interested i that feature.
As pemen said, please tell us which is your detailed idea... and no doubt to contact me.
Luck!...
Gus Pilla (nekro)
Logged In: YES
user_id=700563
Originator: YES
OK Gus, I'll run something up as soon as I can.
A
Logged In: YES
user_id=700563
Originator: YES
RFC - Hooks for Module Developers
Initial Author: akitson (Ashley Kitson)
Date 06/06/2007
Objective
This functional requirement is for the Xoops CMS and is aimed at providing hooks into the Xoops core where module developers can extend the functionality of the core. The primary aim is to avoid end users having to hack core files in order to make certain modules work.
Classic examples of this are:
Peak's Protector - requires mainfile.php to be hacked in order to provide site security
XBS's Metatags - requires footer.php to be hacked to provide MetaTag Keyword optimisation
There are others.
Limitations
Xoops is not event driven. If it were then module developers could hook into events to provide this functionality. Xoops is (currently) mainly procedural and this puts a limitation on how this functionality can be added to it. Any technical design that is a result of this requirement should bear in mind what is likely to happen in the future and should be written to take advantage of the core objects within Xoops so that any future changes in Xoops core processing strategy can take this functionality with it.
As a result of this limitation, some thought needs to be put into where hook points are placed in the xoops core files.
Design proposal
1/ A new class (inherited from XoopsObject) is defined: XoopsHook()
XoopsHook() has an underlying data table to store non transitory information.
All processing of hooks is done via XoopsHook().
2/ xoops_version.php for modules is extended to allow $modversion[] to carry new data for module installation i.e.
$modversion['hook'][$n]['file_to_run'] = "example.php";
$modversion['hook'][$n]['file_where_run'] = "mainfile.php";
$modversion['hook'][$n]['stage_where_run'] = 1;
A new subdirectory for modules is defined called 'hooks' where hook files are located, e.g. in this example for a module called 'mymodule', the hook is in XOOPS_ROOT_PATH/modules/mymodule/hooks/example.php.
Module installation processes this new $modversion information and stores it in the hooks data table, e.g.
Table xoops_hooks
id : 1
modid : 23
file_where_run: mainfile.php
stage_where_run: 1
file_to_run: example.com
run_order: 0
3/ Deinstallation of the module clears any hook data. Any module update must be handled to cater for changed hooks.
4/ A new administration screen is provided that allows the administrator to;
a - change the run order of multiple hooks vying for the same file and stage spot
b - deactivate/activate a hook (deinstallation of a hook occurs when the module is deinstalled)
5/ A singleton xoops_hook() object is instantiated on Xoops Core startup that reads in the data for the hook table and stores in memory.
6/ At strategic points in mainfile.php, footer.php and header.php (as a starting point - we need to canvas module developers here,) a call is made to xoops_hook() object i.e.
xoops_hook->run($current_file_name,$stageId);
This call quickly sees if any code is 'hooked' in and if required, runs it.
7/ Documentation is provided for developers to allow them to create hooks - and as importantly, rules and parameters are set within which such hooks must run.
Caveat
There may be better ways of doing this.
Logged In: YES
user_id=1129857
Originator: NO
Hi devs and special Nekro.
We will talk more about this.
The road is informed and believe that it would be very similar to what idealizamos for pre_carga, but in a different way and using plugins within the directory of each module, and simpler.
The idea of an object Hook () is also excellent, but could make the destination the plugins.
With a file like this can be controlled in the work necessary and also make it much easier it is the developer of modules or even for themes.
We will talk more about this?
in portuguese:
Vamos falar mais sobre este assunto.
O caminho está informado e acredito que seria muito similar ao que idealizamos para o pre_carga, mas de uma forma diferente e utilizando plugins dentro do diretório de cada módulo, bem mais simples.
A idéia de um objeto Hook() é excelente também, mas poderia dar o destino a plugins.
Com um arquivo como este poderemos de forma controlada dar o trabalho necessário e também facilitar muito o desenvolvedor seja ele de modulos ou mesmo para themes.
Vamos falar mais sobre este assunto ?