New hooks for local plugins (or new system driven events)

New hooks for local plugins (or new system driven events)

by Juan Leyva -
Number of replies: 10
Picture of Core developers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

So I want to create a “New feature” META issue in the tracker regarding local plugin hooks (or new events). Before creating it I want some feedback from other developers.

Since I’m a contrib developer (and work also for a Moodle Partner) I’m a huge fan of local plugins mainly due to the hooks and libraries that allows me to not to change Moodle core code.

I think that the current hooks for local plugin are very limited, so I want to propose a few new ones.
I’m also suggesting that instead adding new hooks for local plugins, it will be interesting check if add new “system driven” events will be plausible. The curren event system in Moodle is designed for being “user driven” (user created, user deleted, quiz graded)

Hooks or new events:


Once the initial Moodle setup is finished (afer loading config.php in every page that includes it)
New hook for local plugins or new event “setupfinished”
This can be achieved using “customscripts” but I think that using local hooks will be a best choice.
When I mean hook I mean a function in the lib.php of the local plugin called

local_pluginname_setup_finished()

that is called when the setup finishs

Before page header printing (print_header)
After page header printing

Same for page footer

These hooks will help us to easily manipulate the OUTPUT and PAGE objects before printing

Hooks for manipulating the settings tree (currently there is a hook for the navigation tree)

More ideas:

Renderes for local plugins that overwrites the themes one

Average of ratings: -
In reply to Juan Leyva

Re: New hooks for local plugins (or new system driven events)

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

You can do all of the things you want if you are using a custom theme, since you can do them in the theme, for example in renderers.

You can also do some of them using $CFG->moodlepageclass = 'my_hacked_moodle_page'; in config.php to tell Moodle to use a custom subclass of moodle_page. (See explanation in config-dist.php.)

I am not really a fan of adding arbitrary hooks that let you do hacky things. I think it would be better to talk about the specific use-cases you have, and to try to find non-hacky ways to expand Moodle's APIs to encompas them.

 

On the subject of renderers, I do recall a discussion about having a more flexible way to select renderers. At the moment, each plugin can define its own renderer, and then the theme can override them if it chooses (using $THEME->rendererfactory = 'theme_overridden_renderer_factory';)

Note from that that the theme can specify any renderer factory that it likes, which gives a lot of flexibility - but all in the hands of the theme. Anyway, the discussion was about whether we should make a more sophisticated renderer factory that would allow you to create sort-of renderer mix-ins, that could be used in combination with any theme, without necessarily having to alter that theme, to achieve various output changes.

Average of ratings: -
In reply to Tim Hunt

Re: New hooks for local plugins (or new system driven events)

by Hubert Chathi -

As a concrete example that sounds similar to something Juan mentioned (manipulating the settings tree), it would be useful for plugins to be able to add items to the "My profile settings" tree.  My OpenID provider plugin wants to allow users to modify trusted host settings, and the ideal place to put that is in the user's settings tree, but AFAICT, I can't do that without patching lib/navigationlib.php (which is one reason that the plugin isn't approved yet -- MDLSITE-1641).

Average of ratings: -
In reply to Hubert Chathi

Re: New hooks for local plugins (or new system driven events)

by sam marshall -
Picture of Core developers Picture of Peer reviewers Picture of Plugin developers

Agree, I'm not too familiar with that area of code but that definitely sounds like a useful one.

(Note: We would like a nicer way to remove things from the settings tree as well...)

--sam

Average of ratings: -
In reply to Hubert Chathi

Re: New hooks for local plugins (or new system driven events)

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

OK, but here is a situation where it would be good to have a proper solution.

We have a nice system for admin configuration settings, where for each Moodle configuration setting, there is a setting object that defines what the setting is, what the default is and what the permitted values are. This lets most of the admin UI be built fairly automatically - and any plugin can have settings defined in a settings.php file.

Jenny Gray has proposed a similar system for user-preferences, so that user-preferences can be nicely exposed in the UI to the user - and all types of plugin can advertise their user preferences in this way. It seems like a good idea to me. It is just a matter of someone doing the work.

Average of ratings: -
In reply to Tim Hunt

Re: New hooks for local plugins (or new system driven events)

by sam marshall -
Picture of Core developers Picture of Peer reviewers Picture of Plugin developers

I definitely like the proposal Tim mentioned.

For anyone who didn't follow, that suggestion is basically to have a new 'custom renderer' plugin type that lets you override any renderer(s) independently* from the theme. This would solve the 'you can only fix this problem in a theme' issue.

*ish

Our OU theme, for instance, is probably about 40% visual styling and about 60% custom functionality that happens to be only possible in renderers. smile This isn't really a great way to organise customisations.

--sam

Average of ratings: -
In reply to sam marshall

Re: New hooks for local plugins (or new system driven events)

by Juan Leyva -
Picture of Core developers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

More than having a custom renderer plugin I suggest that any type of plugin should have a speciall class in the lib.php for this. 

So custom renderers are loadded every time from every plugin. but this may causes conflicts if there are more than one pplugin overwriting some parts of the render.

Is the same that the cron function that is present in all type of plugins.

Average of ratings: -
In reply to Tim Hunt

Re: New hooks for local plugins (or new system driven events)

by Juan Leyva -
Picture of Core developers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

I was suggesting hooks because is the way in Moodle core is working:

Check the new type of plugin "report" in Moodle 2.2

https://github.com/moodle/moodle/blob/master/report/stats/lib.php#L37

Functions:

report_stats_extend_navigation_course($navigation,$course,$context)

report_stats_extend_navigation_user($navigation,$user,$course)

Why this functions are limited to reports?

It would be amazing having a

local_plugin_extend_navigation_course

local_plugin_extend_navigation_user

Also, the current settings.php only works for global settings, not for all the settings displayed in the settings block.

Theme renderers also does not allow developers to inject code after setup (config.php) is finished

Currently there is a way since Moodle 1.5 for doing it using customscrtips but is not a good way because it requires create a new php script for each Moodle php you want to inject code in a special location.

Average of ratings: -
In reply to Tim Hunt

Re: New hooks for local plugins (or new system driven events)

by Juan Leyva -
Picture of Core developers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

Some specific-use cases:

Plugin LTI Provider:

I need to unset a new CFG present in Moodle 2.2 that avoid Moodle to be embedded in an iframe.
This has to be done in every single Moodle page if a SESSION value setted by my plugin is present.
So I need a way to inject some code before print_header happens or any header is sent by Moodle, the best place is right after config.php

 A hook in the lib/setup will be very helpfull

Plugin anonymous posting

I need to change the settings block (module and user level) for adding some options.
A hook in the navigation and settings block when the full tree structure is loaded will be very usefull.  This hook is yet present in the navigation block

Average of ratings: -
In reply to Juan Leyva

Re: New hooks for local plugins (or new system driven events)

by Charles Severance -

Juan, I don't want to distract the main topic, but I don't think you need what you are asking for for the Basic LTI Provider.   You simply need to suppress the CFG option on the launch url and then later in the code for launch, simply check the cfg option and then do an open in new window via JavaScript instead of redirect and I then the rest of the pages function perfectly with the header set per the wishes of the admin.   If the admin wants to let it work in the iframe, simply change the cfg globally and your code will then let the tools/courses nestle snugly in the iframe.

Again, I don't intend to distract from your high level conersation about more places to add plugins.

Average of ratings: -