#256 Provide hooks for modules

XOOPS_2.x
open
Core (214)
5
2012-09-25
2007-06-30
Ashley
No

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.

Discussion

  • pemen

    pemen - 2007-07-02

    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.

     
  • Ashley

    Ashley - 2007-07-02

    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

     
  • nekro ( XOOPS )

    nekro ( XOOPS ) - 2007-07-03

    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)

     
  • Ashley

    Ashley - 2007-07-06

    Logged In: YES
    user_id=700563
    Originator: YES

    OK Gus, I'll run something up as soon as I can.
    A

     
  • Ashley

    Ashley - 2007-07-06

    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.

     
  • GibaPhp

    GibaPhp - 2007-10-24

    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 ?

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks