Hooks spec

Moodle hooks/features (Specification for 2.6)

Summary

Allow plugins to substitute or extend some core code where change is not big enough to create a new plugin type but we want to allow plugins interactions. Create management UI where admin can see the list of all available hooks/features definitions and available implementations, enable/prioritise implementations.

Current workarounds

• Events system. The core notifies whoever wants to listen to it about something that happens. Disadvantage: one-way communication, no feedback.

• Defining functions in /plugindir/lib.php with the name <pluginname>_<hookname> and querying all plugins if somebody implements function and/or list of plugins implementing it. Disadvantage: functions must be defined in lib.php therefore they are always included (performance loss); no UI to configure if only one plugin can implement feature; difficult for developers because they don't know if they can or how they can implement a hook.

• $CFG variables. Disadvantage: they should be used for settings and not for including the 3rd party code

• Creating a new plugin type. Disadvantage: very long process, involves lots of documentation, creating lots of strings and UI, may be available in major releases only. Also not applicable for minor features.

Implementation

• All hooks/features definitions are stored in /db/ folder (of core or plugin). It's best to implement definitions as interfaces or parent classes, this way PHP will make sure that implementations exactly match the definition.

• All implementations are also stored in plugin in particular place. Maybe folder /hooks/ or /features/ or specific file(s) name(s).

• The definitions and implementations are analysed during install/upgrade only. They are stored in DB, so we include files when and only when we need them.

• There is an administrative management interface that allows to review all available implementations, prioritise and/or disable them. By default the implementations are disabled but admin receives a notification during install/upgrade that new implementations are available and may be enabled.

Use cases

• Course search: we have quite primitive course search algorithm in core. Some other plugin may implement search with sorting by relevance, analysing tags, going through attached pdf files, etc. Hook implementation returns the list of courses and core goes back to the core/theme renderers to display this list

• Global search: similar to above but result will be list of title+url+abstract

• Front page: We have $CFG->customfrontpageinclude for including a file displaying frontpage contents. It could be also hook/feature

• Extending mimetypes list

• Extending licenses list

• Logging (instead of using events functionality)

• Adding fields to the standard forms. This may be a comprehensive feature that includes several functions - adding fields, validation, processing.

• Hooking into backup/restore process. Example when plugin wants to add some field to the course, for example "classroom", and make sure that it is backed up/restored.