Moodle Plugin Process
While outlining our process for requesting, reviewing and recommending plugins we thought it
might be useful to provide a reminder of what Moodle stands for - Modular Object-Oriented
Dynamic Learning Environment. The most sustainable way of extending the functionality of Moodle
is to draw on the Modular element by adding plugins. Plugins are a flexible tool set that can be
installed to extend on Moodle's features. Plugins cover a range of functionality from integration
plugins for third party tools that require a licence (e.g. Turnitin and Kaltura) to new activities (e.g.
Scheduler) and course formats (e.g. collapsed topics)
When are new plugins installed?
Plugins are normally installed once a year in line with the annual upgrade (June-July). This ensures
that information about new plugins is built into communications around changes to functionality
with the latest Moodle upgrade and training on how to use these effectively is included in
Refresher Training for staff. Some plugins such as third-party integrations like Turnitin require a lot
of testing and may restrict the number of small plugins that we can install with the annual upgrade.
When are plugins removed?
Plugins are removed in line with the annual upgrade. Education, Research & Enterprise Services
(ERES) in IS run reports on activity use in Moodle which helps the Educational Technology Team
(ETT) and ERES to identify plugins not being used. We remove unused plugins to provide a more
streamlined experience for staff and to ensure that we are not providing an overwhelming amount
of options when developing modules. New functionality which comes with Moodle upgrades also
makes some of our live plugins redundant. ERES will remove any plugin where functionality is
provided in a core part of our upgraded Moodle. Plugins can be made unavailable in three ways.
1. Available and managed via use of roles and capabilities. (This method would be used where
a plugin might be useful to some, but not all users.)
2. Unavailable
3. Uninstalled (non-core only.)
Note: We would not uninstall core Moodle components, only 3rd party plugins that were no longer
needed.
When we make plugins unavailable; all users will be communicated with via our upgrade
communications plan and we will be clear on the rationale for making a plugin unavailable and the
alternative available.
How are plugins requested?
There are a number of different mechanisms that the ETT use to identify teaching and learning
requirements and what plugins might help provide a solution.
 Responses to the Annual Educational Technology Survey. We analyse staff priorities around
Moodle and identify if there are appropriate plugins that will provide a solution where the
functionality does not already exist in Moodle.
 School relationship leads and educational technologists work closely with academics and
share school needs and developments that are required for upcoming projects. LEaD and
ERES review if any plugins will help meet these requirements.
1



Moodle usability testing may also highlight a requirement that could be met by the
installation of a particular plugin.
Academic and Professional staff make requests directly to Service Now about a teaching or
learning activity that they are trying to set up in Moodle. If this is something that can't be
done with our current functionality we investigate if any of the plugins can meet the
requirements. (Please note: If we find a suitable plugin it will not normally be installed until
the annual Moodle upgrade is carried out.)
ETT and ERES keep abreast of the latest plugin releases in order to identify if any new
plugins can improve the student experience.
ETT requests plugins by the end January for ERES to make available for testing on a development
version of the upgraded Moodle.
What is the review process for a plugin?
There is a two stage review process for plugins.
1. ERES advise as to whether a plugin is developed by an established Moodle development team
or developer. This is important as we need to ensure that the plugin is kept up-to-date as
Moodle is upgraded. ERES also advise if the plugin will impact on Moodle performance. If the
plugin is expected to impact negatively on Moodle performance it will not move to stage 2 of
the review process. In these cases ERES will feedback to the plugin requestor (normally the ETT;
the ETT in turn will feedback to requestor in School if this is the route by which the plugin was
requested.)
2. The ETT review the plugin from a pedagogical perspective to ensure that it meets teaching and
learning requirements for which it may be used. There is a limit to the number of scenarios that
can be tested and we will not be able to test every possible use for a plugin, but we test
common uses and any specific uses that we are aware of. Where a plugin might have quality
implications we also consult with Student and Academic Services. ETT assess whether the
plugin is easy for staff and students to use. If the plugin meets requirements, but is confusing to
use we request changes to settings to improve the set up. ERES provide feedback on whether
these changes are possible.
What is the approval process for a plugin?
Once the plugin has been reviewed, ETT makes a recommendation as to whether a plugin should
be installed, installed to a limited user group (managed via roles) or not installed and provide the
rationale and review results to the Operational Group1. The Operational Group makes the final
decision on the suitability of the plugin. Plugins that are to be removed are also agreed by the
Operational Group.
If the plugin is agreed then ERES include this in their annual upgrade. ETT produce guidance on
how to use the plugin effectively. If the plugin is not approved; ETT provides feedback to the plugin
requestor. Information about the functionality and effective use of new plugins are included in
communications related to the annual Moodle upgrade.
When are bespoke plugins developed?
A bespoke plugin will only be developed where there is a strong case for functionality that cannot
be provided by core Moodle functionality or actively maintained 3rd party plugin. The case will be
1
The Operational Group meets to discuss operational issues around Educational Technology and seek
decisions from key representatives from each of the teams (LEaD and IS) involved in supporting these
technologies.
2
stronger for functionality required across the University rather than for just 1 school or
department. Custom development will only be carried out in line with current Moodle
programming guidelines and wherever possible custom developments will be made available under
GNU licence (open source).
In line with other plugins we would prefer to release bespoke plugins only during the annual
upgrade and thereafter provide updates and incremental improvements as part of any minor
releases as scheduled throughout the year.
Why are certain Moodle upgrade features switched off?
ETT will occasionally make a decision not to switch on part of the upgraded Moodle functionality.
These decisions are made if the new functionality impacts on University processes or where the
functionality requires access to an external system that is not used at City. Examples of this include:
Open badges: ETT made the decision to switch off badges with the upgrade to Moodle 2.6 as we
recognised the need for an institutional badging process. Through issuing badges we, as a
University are recognising and endorsing the value of the badges that we issue, and we need to
discuss these implications with Student and Academic Services.
Upload from OneDrive: OneDrive has not yet been fully released across the University. For this
reason we did not activate the upload option from OneDrive with the move to Moodle 2.6.
Where can I find out more about plugins?
Subscribe to the Plugins traffic forum to monitor latest news. Check Moodleplugins RSS feeds for
recently released plugins, new plugins or updated plugins or follow @moodleplugins on Twitter.
3