Filter plugins
Filters are a way to automatically transform content before it is output. Filters may be used to:
- Render embedded equations to images (the TeX filter).
- Automatically convert links to media files to embedded players.
- Automatically convert mentions of glossary terms to links.
Filters are one of the easiest types of plugin to create.
Filters are applied to content passed into the format_string()
and format_text()
functions, which are part of the Output API.
File structure
Filter plugins are located in the /filter
directory.
Each plugin is in a separate subdirectory and consists of a number of mandatory files and any other files the developer is going to use.
View an example directory layout for the filter_pluginname
plugin.
Some of the important files for the filter plugintype are described below. See the common plugin files documentation for details of other files which may be useful in your plugin.
filter.php
Filter main class
File path: /classes/text_filter.php
View example
version.php
Version metadata
File path: /version.php
The version.php contains metadata about the plugin.
It is used during the installation and upgrade of the plugin.
This file contains metadata used to describe the plugin, and includes information such as:
- the version number
- a list of dependencies
- the minimum Moodle version required
- maturity of the plugin
View example
lang/en/filter_pluginname.php
Language files
File path: /lang/en/plugintype_pluginname.php
Each plugin must define a set of language strings with, at a minimum, an English translation. These are specified in the plugin's lang/en
directory in a file named after the plugin. For example the LDAP authentication plugin:
// Plugin type: `auth`
// Plugin name: `ldap`
// Frankenstyle plugin name: `auth_ldap`
// Plugin location: `auth/ldap`
// Language string location: `auth/ldap/lang/en/auth_ldap.php`
Every plugin must define the name of the plugin, or its pluginname
.
The get_string
API can be used to translate a string identifier back into a translated string.
get_string('pluginname', '[plugintype]_[pluginname]');
- See the String API documentation for more information on language files.
View example
Test a filter
To enable a filter, go to the filters administration screen and set the filter active to "On".
Filters are applied to all text that is printed with the output functions format_text()
and format_string()
. To see a filter in action, add some content to a label resource. When you look at that course in the course listing, you should see that your filter has transformed the text accordingly.
Filter performance
It is important to note that all active filters will be called to transform every bit of text output using format_text()
(headers and content), and format_string()
(headers only). As a result a filter plugin can cause big performance problems. It is extremely important to use cache if your filter must retrieve data from the database, or other similar sources.
If a filter uses a special syntax or it is based on an appearance of a substring in the text, it is recommend to perform a quick and cheap strpos()
search first prior to executing the full regex-based search and replace.
View example
Local configuration
Filters can use different configuration depending on the context in which they are called. For example, the glossary filter can be configured such that when displayed in Forum A it only links words from a particular glossary, while in Forum B it links words from a different glossary..
To support this behaviour, a filter plugin must provide a filterlocalsettings.php
file which defines a Moodle form which subclasses the filter_local_settings_form
class. In addition to the standard formslib methods, you must also define a save_changes
method.
View example
All the local configurations can be accessed in the main filter class in the $this->localconfig
property.
View example
Filtering dynamic content
It is possible that page content is loaded by ajax after the page is loaded. In certain filter types (for example MathJax) JavaScript is required to be run on the output of the filter in order to do the final markup. For these types of filters, a JavaScript event is triggered when new content is added to the page (the content will have already been processed by the filter in php). The JavaScript for a filter can listen for these event notifications and reprocess the affected dom nodes.
The content updated event is registered in the core_filters/events
module and can be imported as:
import {eventTypes} from 'core_filters/events';
document.addEventListener(eventTypes.filterContentUpdated, eventHandler);