Output callbacks

Jump to: navigation, search

There are cases where we want any plugin to contribute to a chunk of the output of any given page. We want this to be loosely coupled so you don't have say an admin tool's code leaking into your theme. In the past many plugins had an installation step like "Copy this into your theme header" which is what we want to completely avoid.

There are a variety of Callbacks which enable any plugin to add or modify certain parts of the output and at certain stages in the rendering process. These callbacks are probably most useful for local plugins or admin tools which bring some functionality to the whole site instead of just certain pages. But they can also be used by any plugin to conditionally augment the output too.


Moodle 3.3

This is used to append extra attributes into the html element of the page which are required elsewhere. An example might be a facebook block plugin which uses the opengraph js libraries which need the xml namespace to be setup. It should return an array of attribute key and values like this:

function tool_facebook_add_htmlattributes() {
     return array(
         'xmlns:og' => 'http://ogp.me/ns#',

Because multiple plugins can add extra attributes there is potential namespace clash issues. ie in the Facebook opengraph example stick with "xmlns:og" as specified by Facebook so that if multiple plugins declare the same key / value then they will match. Not that duplicates attribute keys are merged.


Moodle 3.3

This enables you to easily inject a chunk of JS or CSS into every page, for instance an analytics tool like Google Analytics or Facebook pixel. It only has side effects and it's return value is ignored:

function tool_mytool_before_footer() {
    global $PAGE;


Moodle 3.3

This enables you to easily inject a HTTP header into every page. It only has side effects and it's return value is ignored:

function tool_headertest_before_http_headers() {
    header("X-CustomHeader: SomeValue");

Note that this is called after the page is generated and just prior to the headers being sent. So internal system state may have already been changed (eg adding events to the log) and the page generation may have been expensive and the student will be considered to have viewed the page.

You should generally not use this callback for things like redirecting away under some conditions, instead consider either the after_config or the after_require_login callbacks which fire earlier in the request lifecycle.


Moodle 3.3

This is an API alternative to appending to $CFG->additionalhtmlhead and could be used for adding meta tags or similar to the page. It MUST return a string containing well a formed html chunk, or at minimum an empty string.

function tool_headtag_before_standard_html_head() {
    return "<meta name='foo' value='before_top_of_body_html' />\n";


Moodle 3.3

This enables a plugin to insert a chunk of html at the start of the html document. Typical use cases include some sort of alert notification, but in many cases the Notifications may be a better fit. It MUST return a string containing a well formed chunk of html, or at minimum an empty string.

function tool_callbacktest_before_standard_top_of_body_html() {
    return "<div style='background: red'>Before standard top of body html</div>";


Moodle 3.2