Output API
The Output API is responsible for visual aspects of Moodle content. This page explains how renderers, renderables, themes and templates all work together.
Page Output Journey
Let's start with building a page that is part of an admin tool.
<?php
// Standard GPL and phpdocs
require_once(__DIR__ . '/../../../config.php');
require_once($CFG->libdir.'/adminlib.php');
admin_externalpage_setup('tooldemo');
// Set up the page.
$title = get_string('pluginname', 'tool_demo');
$pagetitle = $title;
$url = new moodle_url("/admin/tool/demo/index.php");
$PAGE->set_url($url);
$PAGE->set_title($title);
$PAGE->set_heading($title);
$output = $PAGE->get_renderer('tool_demo');
echo $output->header();
echo $output->heading($pagetitle);
$renderable = new \tool_demo\output\index_page('Some text');
echo $output->render($renderable);
echo $output->footer();
On admin pages, the admin_externalpage_setup($sectionname); function should be called to set up and perform permission checks, for example:
require_once(__DIR__ . '/../../config.php');
require_once("{$CFG->libdir}/adminlib.php");
admin_externalpage_setup('example');
Firstly, we set some general $PAGE properties. We load the title of the page from a language string (see String API).
// Set up the page.
$title = get_string('pluginname', 'tool_demo');
$pagetitle = $title;
$url = new moodle_url("/admin/tool/demo/index.php");
$PAGE->set_url($url);
$PAGE->set_title($title);
$PAGE->set_heading($title);
$PAGE is a global variable used to track the state of the page that is being returned. It is an instance of the moodle_page class defined in lib/pagelib.php. See Page API for more information on the $PAGE variable.
The most important properties stored in $PAGE are the page context, URL, layout, title and headings. $PAGE also gives access to some other important classes such as $PAGE->requires, which is an instance of the page_requirements_manager (lib/outputrequirementslib.php). The page_requirements_manager class lets us set dependencies on e.g. JavaScript and CSS to be inserted in the correct place in the page (The order in which things are inserted into the page is hugely important for performance).
$PAGE also lets us load specific renderers for a plugin, or plugin and subtype. We will cover renderers in more detail next.
$output = $PAGE->get_renderer('tool_demo');
This gets an instance of the plugin_renderer_base class that we use to create all output for our page. Themers can subclass this renderer to override specific render methods in order to customise Moodle's output. See Output renderers for more information, and Overriding a renderer for information about how themers can customise a renderer.
Some pages use the global variable $OUTPUT to generate their output. This is a generic renderer used for core pages etc, but plugins should always use a more specific plugin renderer.
echo $output->header();
echo $output->heading($pagetitle);
This code prints the header of the page and adds one heading to the page at the top of the content region. Page headings are very important in Moodle and should be applied consistently. See HTML Guidelines for more information on how and where to use headings.
$renderable = new \tool_demo\output\index_page('Some text');
echo $output->render($renderable);
This is the most interesting part of our page. We are creating an instance of a renderable and telling our renderer to render it. The renderable is usually more complex than this. It should hold all the data required for the renderer to display the page. This means we should perform all our logic such as database queries, page parameters and access checks in advance then pass the results as data to the renderable. The renderable then just takes that data and returns an HTML representation of it.
echo $output->footer();
This prints the HTML for the bottom of the page. It is very important because it also prints out things that were added to the page_requirements_manager and that need to be printed in the footer; things like JavaScript includes, navigation tree setup, closing open containers tags etc. The reason all JavaScripts are added to the footer of the page is for performance. If you add JavaScript includes to the top of the page, or inline with the content, the browser must stop and execute the JavaScript before it can render the page. See https://developers.google.com/speed/docs/insights/BlockingJS for more information.
Renderable
In the code above, we created a renderable. This is a class that you have to add to your plugin. It holds all the data required to display something on the page. Here is the renderable for this example:
<?php
// Standard GPL and phpdocs
namespace tool_demo\output;
use renderable;
use renderer_base;
use templatable;
use stdClass;
class index_page implements renderable, templatable {
/** @var string $sometext Some text to show how to pass data to a template. */
private $sometext = null;
public function __construct($sometext): void {
$this->sometext = $sometext;
}
/**
* Export this data so it can be used as the context for a mustache template.
*
* @return stdClass
*/
public function export_for_template(renderer_base $output): stdClass {
$data = new stdClass();
$data->sometext = $this->sometext;
return $data;
}
}
This class implements the:
renderableinterface, which has no methodstemplatableinterface, which means that this class could be rendered with a template, so it must implement theexport_for_templatemethod
In this example, the class accepts data via it's constructor, and stores that data in class variables. It does nothing else with the data in this example (but it could). Note that the export_for_template function should only return simple types (arrays, stdClass, bool, int, float, string), or those that implement the Stringable interface.
If you wish to use a specific template to render the content you may specify anyone by replacing templatable with named_templatable, which extends templatable and requires that you implement a get_template_name() method that returns the name of the template you wish to use.
/**
* Gets the name of the mustache template used to render the data.
*
* @return string
*/
public function get_template_name(\renderer_base $renderer): string {
return 'tool_demo/index_page';
}
Now let's look at the renderer for this plugin.
<?php
// Standard GPL and phpdocs
namespace tool_demo\output;
use plugin_renderer_base;
class renderer extends plugin_renderer_base {
/**
* Defer to template.
*
* @param index_page $page
*
* @return string html for the page
*/
public function render_index_page($page): string {
$data = $page->export_for_template($this);
return parent::render_from_template('tool_demo/index_page', $data);
}
}
The renderer exists to provide render_<page> methods for all renderables used in the plugin. A theme designer can provide a custom version of this renderer that changes the behaviour of any of the render methods and so to customize their theme. In this example, the render method for the index page (render_index_page) does 2 things. It asks the renderable to export it's data so that it is suitable for passing as the context to a template, and then renders a specific template with this context. A theme designer could either manipulate the data in the render method (e.g. removing menu entries), or change the template (change the generated HTML) to customize the output.
You do not need to implement a renderer for a plugin if you are using templates and you either:
- Use the
templatableinterface and have a template with the same name in the same namespace - Use the
named_templatableinterface
In these cases the data from the renderable will be automatically routed to the correct template, however if you do implement a render method that will be used in preference to the default routing.
The template used in this plugin is located in the plugin's templates folder. The template can also be overridden by a theme designer.
<div class="hero-unit">
<h1>Heading</h1>
<p>{{sometext}}</p>
</div>
This is the mustache template for this demo. It uses some bootstrap classes directly to position and style the content on the page. {{sometext}} is replaced with the variable from the context when this template is rendered. For more information on templates see Templates.
Output Functions
This section explains how dynamic data should be sent from Moodle to the web browser in an organised and standard way.
It is possible to have your own output methods but, thinking that you are going to share your code (yep, this is an OpenSource project!) and in the collaborative way we try to build and maintain the system every day, it would be really better to follow the basic guidelines explained below.
By using them you will be helping to have better, more secure and readable code. Spend some minutes trying to understand them, please!
Of course, these functions can be discussed, modified and new functions can arrive if there are some good reasons for it. Just discuss it in the General developer forum.
For each of the functions below we'll try to explain when they should be used, explaining the most important parameters supported and their meaning. Let's review them!
String formatting functions
The format_string and format_text functions should always be used when preparing the output of information. They may also be used to process information before it is stored in the database however, filters should only be applied at output. For example, language filters must only be applied as the content is prepared for output because we don't yet know the user's preferred language.
p() and s()
function s($var, $strip=false)
function p($var, $strip=false)
The only difference between these two functions is that s() returns the string, while p() prints it directly.
These functions should be used to:
- Print all the values of form fields like
<input>or<textarea>tags. - Print plain (non-HTML) text that has been introduced by the user (search string, quiz responses, ...).
- Print in general as long as the text does not need to be cleaned or processed by filters.
- Print HTML source code instead of rendering it.
The functions replace certain characters that have a special meaning in HTML (<, >, ", ', and &) with HTML entities so that they are displayed as intended. Note that even though the value of form fields printed with p() will have these characters converted to HTML entities, the submitted values will still contain the original characters.
The key parameter for this function is:
strip: Set totrueto strip slashes from the string. Only set this parameter totruewhen the data to be processed is not coming from the database. This should be used when the string comes from HTTP requests (forms, links, ...). (Default isfalse, so no strip will be performed)
format_text()
function format_text(
string $text,
$format = FORMAT_MOODLE,
[
'noclean' => false,
'trusted' => false,
'filter' => true,
'context' => $context,
'para' => true,
'newline' => true,
'allowid' => false,
'blanktarget' => false,
],
);
This function should be used to:
- print any html/plain/markdown/moodle text, needing any of the features below. It is mainly used for long strings like posts, answers, glossary items, etc.
- filter content through Moodle or 3rd party language filters for multi-language support. This is not to be confused with get_string which is used to access localized strings in Moodle from its language packs. Together, these functions enable Moodle multi-language support. Note that this function is process intensive because it supports cleaning of dangerous contents, delegates processing to enabled content filters, supports different formats of text (HTML, PLAIN, MARKDOWN, MOODLE) and performs a lot of automatic conversions like adding smilies, build links. Also, it includes a strong cache mechanism (DB-based) that will alleviate the server from a lot of work processing the same texts time and again.
Some interesting parameters for this function are:
- format: This parameter specifies the format of the text.
FORMAT_MOODLEis a useful format for processing plain text because it features automatic rendering of links and smilies, and does a good job of converting plain text to HTML output. Other supported formats includeFORMAT_HTML,FORMAT_PLAIN,FORMAT_MARKDOWN. (Default isFORMAT_MOODLE) - options: Here we can specify options for processing the text. You only need to define them if they are different from the default values. The main options are:
options->noclean: Set totrueto skip the clean-up of text, un-protecting us from attacks and other security flaws. You should never set it totrueunless you are 200% sure that only trusted users can edit the content such as site administrators. Never use it for user-submitted text (posts...) or you will be attacked sooner or later! Note that this option is ignored forFORMAT_PLAINwhere the text is never cleaned. (Default isfalse, so protection is enabled)options->trusted: Set totrueif the content is trusted and does not need clean-up. This argument is only enabled if$CFG->enabletrusttextis also set totrue. It is ignored ifnocleanis specified. (Default isfalse)options->filter: Set tofalseif you do not want to allow filters to process the text. This is ignored byFORMAT_PLAINfor which filters are never applied. (Default istrue)options->context: If text is filtered (and this happens by default), it is very important to specify the context (id or object) for applying filters. If context is not specified it will be taken from$PAGE->contextand may potentially result in displaying the same text differently on different pages. For example, all module-related information should have module context even when it appears in course-level reports, all course-related information such as name and description should have course context even when displayed on the front page or system pages.options->para: Set tofalseif you do not want every paragraph to automatically be enclosed between HTML paragraph tags (<p>...</p>). This option only applies toFORMAT_MOODLE. (Defaults istrue)options->newlines: Set tofalseif line feeds in text should be converted to HTML newlines (<br />). This option only applies toFORMAT_MOODLE. (Default totrue)options->overflowdiv*: Set totrueif you want the formatted text to automatically be encased in a div with the class no-overflow before being returned. (Default isfalse)options->allowid: Set totrueto ensure that the id attributes will not be removed, even when using HTML Purifier. (Default isfalse)options->blanktarget: Set totrueto havetarget="_blank"added to all<a>tags unless the target attribute is explicitly specified. (Default isfalse)
format_string()
function format_string(string $text, $striplinks = true, ['context' => $context, 'escape' => true, 'filter' => true])
This function should be used to:
- print short non-html strings that need filter processing (activity titles, post subjects, glossary concepts...). If the string contains HTML, it will be filtered out. If you want the HTML, use
format_text()instead. - filter content through Moodle or 3rd party language filters for multi-language support. Not to be confused with get_string which is used to access localized strings in Moodle and its language packs. Together, these functions enable Moodle multi-language support. All enabled heading filters will be applied to the string.
Please note that this function is a stripped version of the full format_text() function detailed above. It does not offer any of its options or protections. It simply filters the strings and returns the result, so we must ensure that the string has been processed properly and cleaned at input time using the proper xxx_param() functions.
Some interesting parameters for this function are:
striplinks: Set tofalseto keep all links after the text has been processed by filters. Used when we want to show the text inside menus, page titles, etc. (Default istrue)optionsoptions->context: Context (id or object) for applying filters. If context is not specified it will be taken from$PAGE->contextand may potentially result in displaying the same text differently on different pages. For example, all module-related information should have module context even when it appears in course-level reports, all course-related information such as name and description should have course context even when they are displayed on the front page or system pages.options->escape: Set tofalseif you do not want to escape HTML entities. (Default istrue)options->filter: Set tofalseif you do not want to allow filters to process the text. This is ignored byFORMAT_PLAINfor which filters are never applied. (Default istrue)
Simple elements rendering
Those methods are designed to replace the old html_writer::tag(...) methods. Even if many of them are just wrappers around the old methods, they are more semantic and could be overridden by component renderers.
While to render complex elements, you should use templates, some simple elements can be rendered using the following functions:
container()
function container(string $contents, ?string $classes = null, ?string $id = null): string
This function should be used to:
- Print a basic div container with the given contents, classes and id.
Some interesting parameters for this function are:
contents: The contents of the container.classes: The classes of the container. Note that this parameter is a comma-separated list of classes, not an array.id: An optional id of the container.
paragraph()
function paragraph(string $contents, ?string $classes = null, ?string $id = null): string
This function should be used to:
- Print a basic p paragraph with the given contents, classes and id.
Some interesting parameters for this function are:
contents: The contents of the paragraph.classes: The classes of the paragraph. Note that this parameter is a comma-separated list of classes, not an array.id: An optional id of the paragraph.
sr_text()
function sr_text(string $contents): string
This function should be used to:
- Print an inline text for screen readers only.
Some interesting parameters for this function are:
contents: The contents fo screen readers.
In the standard Boost theme this method will output a span using the Bootstrap screen reader class:
<span class="sr-only">Contents</span>
Other
Progress Bars
There are two types of progress bars you can use in Moodle.
Standard Progress Bars
The first is the old standard progress bar which updates as the page loads (ie. the page won't fully load until the progress bar is finished). It can be used to render the current process on the page, or via cli to render the progress of a script.
Example:
<?php
define('NO_OUTPUT_BUFFERING', true); // Required if not used via cli.
require 'config.php';
$PAGE->set_context(context_system::instance());
$PAGE->set_url('/');
echo $OUTPUT->header();
$pb = new \core\output\progress_bar('bar', 500);
$pb->create();
$num_tasks = 500; // the number of tasks to be completed.
for($cur_task = 0; $cur_task <= $num_tasks; $cur_task++)
{
for ($i=0; $i<100000; $i++)
{
;;;
}
$pb->update($cur_task, $num_tasks, 'this is'. $cur_task . 'h');
}
echo $OUTPUT->footer();
Stored Progress Bars
The other type of progress bar you can use is a stored progress bar, which can be used to store and update the progress of a long-running task in the database, and render live updates to the web page via AJAX web service polling.
It can be implemented into a CLI script. Example:
<?php
define('CLI_SCRIPT', true);
require_once('config.php');
require_once($CFG->libdir . '/clilib.php');
$num_tasks = 5000; // the number of tasks to be completed.
$progress = new \core\output\stored_progress_bar('example-cli-bar');
$progress->start();
for($cur_task = 0; $cur_task <= $num_tasks; $cur_task++)
{
$progress->update($cur_task, $num_tasks, 'this is '. $cur_task . '/' . $num_tasks);
}
mtrace('DONE');
Or a scheduled or adhoc task, via a trait. Example:
class stored_progress_scheduled_task_example extends \core\task\scheduled_task {
use \core\task\stored_progress_task_trait;
public function execute() {
// This simulates a specific count of iterations the task will do, e.g. x number of courses to loop through and do something.
$iterations = 100;
$this->start_stored_progress(); // This creates the stored progress record for the named task.
for ($i = 1; $i <= $iterations; $i++) {
// Here we just update and tell it which one we are on and it will work out % from those.
$this->progress->update($i, $iterations, 'i am at ' . $i . ' of ' . $iterations);
sleep(1);
}
return true;
}
}
With the stored progress bars, you can update the progress either via iterations, by passing in the total amount expected and then the current iteration, using ->update()(see: previous example), this will calculate the percentage complete for you. Or you can use ->update_full() to manually set the percentage complete.