MoodleDocs - User contributions [en]

Themes

2019-03-07T02:48:55Z

Stuartrmealor: /* See also */

This page is a starting point for Moodle theme developers.

For documentation on installing and using themes, please see the [[:en:Themes|Themes user documentation]] and [[:en:Themes FAQ|Themes FAQ]].

Moodle has a powerful themes system that allows for a variety of effects through the use of HTML and CSS.

* [[Themes overview]]
* [[Creating a theme based on boost]]
* [[Creating a theme based on classic]]
* [[Moving your theme to use boost as a parent theme]]
* [[Updating a boost based theme]]
* [[Using images in a theme|Using images]]
* [[Creating a theme settings page|Theme settings page]]
* [[Adding theme upgrade code]]
* [[Extending the theme custom menu|Extending the custom menu]]
* [[Overriding a renderer]]
* [[Theme checklist]]
* [[Templates]]

==See also==

* [[:Category:Themes|List of all themes-related developer documentation]]
* [http://youtu.be/K3MYE8am7M4 Install a New Theme] MoodleBites video on YouTube
* Moodle Partner online courses for Theme designers [https://www.moodlebites.com/mod/page/view.php?id=3208 Level 1] (foundation) and [https://www.moodlebites.com/mod/page/view.php?id=3210 Level 2] (advanced)

[[Category:Themes]]

Themes overview

2019-02-05T03:13:19Z

Stuartrmealor: /* The different layouts as of 21st April 2013 */

{{Template:Themes}}
Welcome to the new world of themes in Moodle!

A Moodle theme allows the user to change the look and feel of a Moodle site. Themes can be applied on the site, category, course and activity levels by users with permissions to do so. Themes can be designed for specific devices such as mobile phones or tablets. This page explains how themes work in Moodle and is intended to help you create or modify most themes for Moodle.

You can use contributed themes or create your entire own to share with the community. Themes can also be based on parent themes with only few customizations. Themes accomplish this using CSS, changing the underlying markup structure and also adding Javascript to add more advanced behaviors.

Most theme developers simply add a few changes to their new theme by basing it on an existing one. The Moodle Theme architecture is designed in such a way whereby the base theme will act as a fall-back that is used when nothing has been defined in the theme based on it. This makes it easy to create new themes that simply seek out to make minor changes.

==Whats new?==

When Moodle releases a new version. All changes that affect themes are listed in the theme/upgrade.txt file. This is the most up-to date place to find about all changes to a specific version of Moodle and will always be kept up to date.

[https://github.com/moodle/moodle/blob/master/theme/upgrade.txt View upgrade notes]

==The structure of a theme==

Some important things to know when building good themes:

# '''config.php''' - this file is required in every theme. It defines configuration settings and definitions required to make the theme work in Moodle. These include theme, file, region, default region and options.
# '''Layouts and layout files''' - in config.php there is one definition for each page type (see [[#theme_layouts_table|Appendix A: Theme layouts]] for a list of over 12 types). Each page type definition tells Moodle which layout file will be used, what block regions this page type should display and so on. The layout file contains the HTML and the minimum PHP required to display basic structure of pages.
# '''The boost theme''' - is intended to be the best theme to use as a starting point for building a new theme. It supports all the latest theme features and it tries to stay as true to the [http://getbootstrap.com/ Bootstrap] css framework as possible. [[Creating a theme based on boost]]

===Files and folders===
A theme's files are placed in a folder with under moodle/theme folder and have subfolders. They are laid out like this:

{| class="nicetable"
|-
! Directory
! File
! Description
|-
| /
| config.php
| Contains all of the configuration and definitions for each theme
|-
| /
| lib.php
| Contains speciality functions that are used by theme
|-
| /classes
| *.php
| Contains auto-loaded classes for the theme. See [[Automatic class loading]] for more details.
|-
| /classes/output
| *.php
| This is the location for the theme to define overridden renderers. See [[Output renderers]] for more details.
|-
| /
| settings.php
| Contains custom theme settings. These local settings are defined by the theme allowing an administrator to easily alter something about the way it looks or operates. (eg a background colour, or a header image)
|-
| /
| version.php
| Contains the theme name, version number and Moodle version requirements for using the theme
|-
| /fonts/
| *.woff, *.ttf, *.eot, *.svg, *.otf
| Theme fonts (since 2.6).
|-
| /fonts_core/
| *.woff, *.ttf, *.eot, *.svg, *.otf
| Contains fonts that override standard core fonts (since 2.6).
|-
| /fonts_plugins/plugintype/pluginname/
| *.woff, *.ttf, *.eot, *.svg, *.otf
| Contains fonts that override plugin fonts (since 2.6).
|-
| /amd/src/
| *.js
| All specialty JavaScript files the theme requires should be located in here. Javascript should be written as an AMD module. For more information see [[Javascript Modules]].
|-
| /lang/[langcode]/
| *.php
| Any special language files the theme requires should be located in here.
|-
| /templates/
| *.mustache
| Contains the mustache template files for the themes. (Including overridden ones). See [[Templates]] for more information.
|-
| /layout/
| *.php
| Contains the layout files for the theme.
|-
| /pix/
| *.png, *.jpg, *.gif, *.svg
| Contains any images the theme makes use of either in CSS or in the layout files.
|-
| /pix/
| favicon.ico
| The favicon to display for this theme.
|-
| /pix/
| screenshot.png
| A screenshot of the theme to be displayed in on the theme selection screen.
|-
| /pix_core/
| *.png, *.jpg, *.gif, *.svg
| Contains images that override standard core images.
|-
| /pix_plugins/plugintype/pluginname/
| *.png, *.jpg, *.gif, *.svg
| Contains images that override plugin images.
|-
| /style/
| *.css
| Default location for CSS files.
|-
| /less/
| *.less
| Default location for Less files if your theme uses less.
|-
| /scss/
| *.scss
| Default location for SCSS files if your theme uses SCSS.
|}

There are also several other places that stylesheets can be included from (see the CSS how and why section below).

It is possible to override icons used in base themes without interfering with core code by placing these in dataroot/pix and dataroot/pix_plugins. Where a theme extends a base theme and provides its own icons, these icons will still be used.

It is possible to override mustache templates used in base themes without interfering with core code by placing these in templates/[componentname]/[templatename].mustache.

==Theme options==
All theme options are set within the config.php file for the theme. The settings that are most used are: parents, sheets, layouts, and javascripts. Have a look at the '''[[#theme_options_table|theme options table]]''' for a complete list of theme options which include lesser used specialised or advanced settings.

===Basic theme config example===
Lets have a look at the boost theme configuration file and the different bits that make it up:
<code php>
defined('MOODLE_INTERNAL') || die();

require_once(__DIR__ . '/lib.php');

$THEME->name = 'boost';
$THEME->sheets = [];
$THEME->editor_sheets = [];
$THEME->scss = function($theme) {
return theme_boost_get_main_scss_content($theme);
};

$THEME->layouts = [
// Most backwards compatible layout without the blocks - this is the layout used by default.
'base' => array(
'file' => 'columns1.php',
'regions' => array(),
),
// Standard layout with blocks, this is recommended for most pages with general information.
'standard' => array(
'file' => 'columns2.php',
'regions' => array('side-pre'),
'defaultregion' => 'side-pre',
),
// Main course page.
'course' => array(
'file' => 'columns2.php',
'regions' => array('side-pre'),
'defaultregion' => 'side-pre',
'options' => array('langmenu' => true),
),
'coursecategory' => array(
'file' => 'columns2.php',
'regions' => array('side-pre'),
'defaultregion' => 'side-pre',
),
// Part of course, typical for modules - default page layout if $cm specified in require_login().
'incourse' => array(
'file' => 'columns2.php',
'regions' => array('side-pre'),
'defaultregion' => 'side-pre',
),
// The site home page.
'frontpage' => array(
'file' => 'columns2.php',
'regions' => array('side-pre'),
'defaultregion' => 'side-pre',
'options' => array('nonavbar' => true),
),
// Server administration scripts.
'admin' => array(
'file' => 'columns2.php',
'regions' => array('side-pre'),
'defaultregion' => 'side-pre',
),
// My dashboard page.
'mydashboard' => array(
'file' => 'columns2.php',
'regions' => array('side-pre'),
'defaultregion' => 'side-pre',
'options' => array('langmenu' => true),
),
// My public page.
'mypublic' => array(
'file' => 'columns2.php',
'regions' => array('side-pre'),
'defaultregion' => 'side-pre',
),
'login' => array(
'file' => 'login.php',
'regions' => array(),
'options' => array('langmenu' => true),
),

// Pages that appear in pop-up windows - no navigation, no blocks, no header.
'popup' => array(
'file' => 'columns1.php',
'regions' => array(),
'options' => array('nofooter' => true, 'nonavbar' => true),
),
// No blocks and minimal footer - used for legacy frame layouts only!
'frametop' => array(
'file' => 'columns1.php',
'regions' => array(),
'options' => array('nofooter' => true, 'nocoursefooter' => true),
),
// Embeded pages, like iframe/object embeded in moodleform - it needs as much space as possible.
'embedded' => array(
'file' => 'embedded.php',
'regions' => array()
),
// Used during upgrade and install, and for the 'This site is undergoing maintenance' message.
// This must not have any blocks, links, or API calls that would lead to database or cache interaction.
// Please be extremely careful if you are modifying this layout.
'maintenance' => array(
'file' => 'maintenance.php',
'regions' => array(),
),
// Should display the content and basic headers only.
'print' => array(
'file' => 'columns1.php',
'regions' => array(),
'options' => array('nofooter' => true, 'nonavbar' => false),
),
// The pagelayout used when a redirection is occuring.
'redirect' => array(
'file' => 'embedded.php',
'regions' => array(),
),
// The pagelayout used for reports.
'report' => array(
'file' => 'columns2.php',
'regions' => array('side-pre'),
'defaultregion' => 'side-pre',
),
// The pagelayout used for safebrowser and securewindow.
'secure' => array(
'file' => 'secure.php',
'regions' => array('side-pre'),
'defaultregion' => 'side-pre'
)
];

$THEME->parents = [];
$THEME->enable_dock = false;
$THEME->csstreepostprocessor = 'theme_boost_css_tree_post_processor';
$THEME->extrascsscallback = 'theme_boost_get_extra_scss';
$THEME->prescsscallback = 'theme_boost_get_pre_scss';
$THEME->yuicssmodules = array();
$THEME->rendererfactory = 'theme_overridden_renderer_factory';
$THEME->undeletableblocktypes = '';
</code>

===Basic theme example settings explained===
First up you will notice everything is added to $THEME. This is the theme's configuration object, it is created by Moodle using default settings and is then updated by whatever settings you add to it.

; $THEME->name : The first setting, is the theme's name. This should simply be whatever your theme's name is, most likely whatever you named your theme directory.

; $THEME->sheets : An array containing the names of the CSS stylesheets to include for this theme. Boost uses scss instead of css so it doesn't list any files here. Note that it is just the name of the stylesheet and does not contain the directory or the file extension. Moodle assumes that the theme's stylesheets will be located in the styles directory of the theme and have .css as an extension.

; $THEME->editorsheets : An array containing the names of the CSS stylesheets to include for the TinyMCE text editor content area. Boost does not list any stylesheets here so TinyMCE will use plain text styles.

; $THEME->layouts : In this example, boost maps each of the 18 different layout types to one of 6 different layout files. For more information see the [[#Layouts|layouts]] section below.

; $THEME->parents : This defines the themes that the theme will extend. Boost has no parents, but if you were extending boost you would list it here like: $THEME->parents = ['boost'];

; $THEME->enable_dock : Boost does not support docking blocks. For a example of a theme with a dock for blocks, see theme_bootstrapbase.

; $THEME->csstreepostprocessor : Boost uses a function to post process the CSS. This is an advanced feature and is used in boost to automatically apply vendor prefixes to CSS styles.

; $THEME->yuicssmodules : This is an old setting that defines a list of YUI css files to load. These files interfere with existing styles and it is recommended to set this to an empty string to prevent any files being included.

; $THEME->rendererfactory : Almost all themes need this setting to be set to 'theme_overridden_renderer_factory' or the theme will not be able to customise any core renderers.

; $THEME->undeletableblocktypes : This is a comma separated list of block types that cannot be deleted in this theme. If you don't define this - the admin and settings blocks will be undeletable by default. Because Boost provides alternate ways to navigate it does not require any blocks.

'''''Note''''': When you first begin writing themes, make sure you take a look at the configuration files of the other themes that get shipped with Moodle. You will get a good picture of how everything works, and what is going on in a theme, simply by reading it and taking notice of what it is including or excluding.

==CSS==
===Locations of CSS files===
First lets look at where CSS can be included from within Moodle:
; \theme\themename\style\*.css : This is the default location for all of the stylesheets that are used by a theme and the place which should be used by a theme designer if this theme is using CSS. Alternatives to CSS are LESS and SCSS which are more powerful, flexible and easier to maintain.

New theme developers should note that the order in which CSS files are found and included creates a hierarchy. This order ensures that the rules, within a theme's style sheets, take precedence over identical rules in other files that may have been introduced before. This can both extend another files definitions (see parent array in the config file) and also ensures that the current theme's CSS rules/definitions have the last say.

There are other locations that can be used (although very rarely) to include CSS in a page. A developer of a php file can manually specify a stylesheet from anywhere within Moodle, like the database. Usually, if code is doing this, it is because there is a non-theme config or plugin setting that contains information requires special CSS information. As a theme designer you should be aware of, but not have to worry about, these locations of CSS files. Here are some examples:

; {pluginpath}\styles.css e.g. \block\blockname\styles.css or \mod\modname\styles.css : Every plugin can have its own styles.css file. This file should only contain the required CSS rules for the module and should not add anything to the look of the plugin such as colours, font sizes, or margins other than those that are truly required.<br />Theme specific styles for a plugin should be located within the themes styles directory.
; {pluginpath}\styles_themename.css : This should only ever be used by plugin developers. It allows them to write CSS that is designed for a specific theme without having to make changes to that theme. You will notice that this is never used within Moodle and is designed to be used only by contributed code.

As theme designers, we will only use the first method of introducing CSS: adding rules to a stylesheet file located in the theme's style directory.
===Better than CSS===
Browsers understand CSS well - but it is hard to write and maintain. The language does not support inheritance and reuse and does not allow configuration with variables. This is why CSS pre-processors were invented. Moodle supports 2 different types of CSS pre-processors (Less and Sass) but the Sass pre-processor is recommended by far.

For more information on Less and Sass see:
* [https://en.wikipedia.org/wiki/Less_(stylesheet_language) Less (wikipedia)]
* [https://en.wikipedia.org/wiki/Sass_(stylesheet_language) Sass (wikipedia)]

To use either one, define $THEME->lessfile = 'filename'; or $THEME->scss = 'filename'; in your themes config.php. Moodle will then use one of it's in-built CSS pre-processor to compile the CSS the first time it is loaded (or everytime if themedesignermode is enabled in $CFG).

===Moodle's core CSS organisation===
The next thing to look at is the organisation of CSS and rules within a theme. Although as a theme designer it is entirely up to you as to how you create and organise your CSS. Please note that none of the themes provided in the standard install by Moodle use CSS stylesheets directly. Instead they use either LESS or SCSS to generate the style sheets. They all list one main LESS or SCSS file named "moodle" in the less or scss folders and this file uses imports to load all other required files.

===How to write effective CSS rules within Moodle===
Writing good CSS rules is incredibly important.

Due to performance requirements and browser limitations, all of the CSS files are combined into a single CSS file that gets included every time. This means that rules need to be written in such a way as to minimise the chances of a collision leading to unwanted styles being applied. Whilst writing good CSS is something most designers strive for we have implemented several new body classes and prompt developers to use appropriate classnames.

====<body> CSS id and classes ====
The ID tag that gets applied to the body will always be a representation of the URI. For example if you are looking at a forum posting and the URI is '/mod/forum/view.php' then the body tags ID will be '#page-mod-forum-view'.

As well as the body's ID attribute the URI is also exploded to form several CSS classes that get added to the body tag, so in the above example '/mod/forum/view' you would end up with the following classes being added to the body tag '.path-mod', '.path-mod-forum'. Note that '.path-mod-forum-view' is not added as a class, this is intentionally left out to lessen confusion and duplication as rules can relate directly to the page by using the ID and do not require the final class.

The body ID and body classes described above will form the bread and butter for many of the CSS rules you will need to write for your theme, however there are also several other very handy classes that get added to the body tag that will be beneficial to you once you start your journey down the rabbit hole that is themeing. Some of the more interesting classes are listed below.

* If JavaScript is enabled then 'jsenabled' will be added as a class to the body tag allowing you to style based on JavaScript being enabled or not.
* Either 'dir-rtl' or 'dir-ltr' will be added to the body as a class depending on the direction of the language pack: rtl = right to left, ltr = left to right. This allows you to determine your text-alignment based on language if required.
* A class will be added to represent the language pack currently in use, by default en_utf8 is used by Moodle and will result in the class 'lang-en_utf8' being added to the body tag.
* The wwwroot for Moodle will also be converted to a class and added to the body tag allowing you to stylise your theme based on the URL through which it was reached. e.g. http://sam.moodle.local/moodle/ will become '.sam-moodle-local—moodle'
* If the current user is not logged then '.notloggedin' will be added to the body tag.
* The course format type will be added such as format-weeks
* The course id, context id and category id are all added as in "course-11 context-616 cmid-202 category-1"
* The pagelayout is added as "pagelayout-incourse"

What does all of this look like in practise? Well using the above example /mod/forum/view.php you would get at least the following body tag:
<code html>
<body id="page-mod-forum-view" class="format-weeks forumtype-social path-mod path-mod-forum safari dir-ltr lang-en yui-skin-sam yui3-skin-sam damyon-per-in-moodle-com--stable_master pagelayout-incourse course-11 context-616 cmid-202 category-1 jsenabled">
</code>

====Writing your rules====

By following the [[CSS coding style]] and CSS best-practices and understanding the [http://htmlhelp.com/reference/css/structure.html#cascade cascading order] of CSS a theme developer will reduce collisions and lines of CSS that is written. CSS classes have been placed where it is believed anyone may want to apply their own styles.

When starting to write rules make sure that you have a good understanding of where you want those rules to be applied, it is a good idea to make the most of the body classes mentioned above.
If you want to write a rule for a specific page make use of the body tag's ID, e.g.:

<code css>#page-mod-forum-view .forumpost {
border: 1px solid blue;
}</code>

If you want to write a rule that will be applied all throughout the forum.:

<code css>.path-mod-forum .forumpost {
border: 1px solid blue;
}</code>

The other very important thing to take into consideration is the structure leading up to the tag you want to style. Browsers apply conflicting styles with priority on the more specific selectors. It can be very beneficial to keep this in mind and write full selectors that rely on the structure of the tags leading to the tag you wish to style.

By making use of body id's and classes and writing selectors to take into account the leading structure you can greatly minimise the chance of a collision both with Moodle now and in the future.

It is also important to write as FEW rules as possible. CSS is extremely hard to maintain and lots of CSS is bad for client side performance. Themes based on the Bootstrap CSS framework can achieve most things without writing a single additional CSS rule. Please read [http://v4-alpha.getbootstrap.com/ the Bootstrap documentation] and learn how to use Bootstrap well to avoid adding unnecessary CSS rules for things already provided by the framework.

==Layouts==
Layouts are defined in '''config.php'''.

All themes are required to define the layouts they wish to be responsible for as well as create; however, many layout files are required by those layouts. If the theme is overriding another theme then it is a case of deciding which layouts this new theme should override. If the theme is a completely fresh start then you will need to define a layout for each of the different possibilities.

It is also important to note that a new theme that will base itself on another theme (overriding it) does not need to define any layouts or use any layout files if there are no changes that it wishes to make to the layouts of the existing theme.

As mentioned earlier, layouts are defined in config.php within $THEME->layouts. The following is an example of one such layout definition:
<code php>
$THEME->layouts = array(
// Standard layout with blocks, this is recommended for most pages with general information
'standard' => array(
'theme' => 'boost',
'file' => 'columns2.php',
'regions' => array('side-pre'),
'defaultregion' => 'side-pre'
)
)
</code>
The first thing Moodle looks at is the name of the layout, in this case it is `standard` (the array key in PHP), it then looks at the settings for the layout, this is the theme, file, regions, and default region. There are also a couple of other options that can be set by a layout.

; theme : is the theme the layout file exists in. That's right: you can make use of layouts from other installed themes. ''Optional''
; file : is the name of the layout file this layout wants to use. ''Required''
; regions : is the different block regions (places you can put blocks) within the theme. ''Required''
; defaultregion : is the default location when adding new blocks. '''Required if regions is non-empty, otherwise optional'''
; options : an array of layout specific options described in detail below. '''Optional'''

The '''theme''' is optional. Normally the the layout file is looked for in the current theme, or, if it is not there, in the parent theme. However, you can use a layout file from any other theme by giving the theme name here.

You can define whatever regions you like. You just need to pick a name for each one. Most themes just use one or both of '''side_pre''' and '''side_post''', which is like 'left side' and 'right side', except in right to left languages, when they are reversed. If you say in config.php that your the layout provides regions called 'fred' and 'barney', then you must call $OUTPUT->blocks_for_region('fred') and $OUTPUT->blocks_for_region('barney') somewhere in the layout file.

The final setting '''options''' is a special case that only needs to be set if you want to make use of it. This setting allows the theme designer to specify special options that they would like to create that can be later accessed within the layout file. This allows the theme to make design decisions during the definition and react upon those decisions in what ever layout file is being used.

One such place this has been used is within the boost theme. If you take a look first at theme/boost/config.php you will notice that several layouts specify options '''langmenu''' and '''nonavbar''' which can both be set to either true or false. The layout options can then be used on the layout .php files, mustache templates and renderers.
<code php>
<?php
$hasnavbar = (empty($PAGE->layout_options['nonavbar']) && $PAGE->has_navbar());
$hasfooter = (empty($PAGE->layout_options['nofooter']));
?>
</code>

==Layout files==
Layout files are used to provide a different layout of the elements of the page for different types of pages in Moodle.

In the config.php for a theme - there is a list of 'layouts' which map a page type to a specific php page in the layout folder for the theme.

For example:
''theme/boost/config.php''
<code php>
...
'popup' => array(
'file' => 'columns1.php',
'regions' => array(),
'options' => array('nofooter' => true, 'nonavbar' => true),
),
...
</code>

This means every page that has pagetype 'popup' will be displayed with the 'theme/themename/layout/columns1.php' file, it will have no block regions and there are some options that will be available to the page in the global variable "$PAGE->layout_options".

It is possible to implement a layout file directly in php by echoing the HTML for the page, or mixing php tags with HTML - but a better way to create a layout file is to gather all the information required for the layout into a context and render it with a mustache template.

[[Templates| Read about mustache templates]]

Using templates for layout files makes a lot of sense because they are easier to read and maintain than mixing PHP and HTML in the same file.

A simple example of a layout file using a template is at:

''theme/boost/layout/columns1.php''
<code php>
<?php

$bodyattributes = $OUTPUT->body_attributes([]);

$templatecontext = [
'sitename' => format_string($SITE->shortname, true, ['context' => context_course::instance(SITEID), "escape" => false]),
'output' => $OUTPUT,
'bodyattributes' => $bodyattributes
];

echo $OUTPUT->render_from_template('theme_boost/columns1', $templatecontext);
</code>

This example puts some variables into a templatecontext and then calls "render_from_template" to render the mustache template for this layout. The template is located at: "theme/boost/templates/columns1.mustache". It is possible to put PHP classes in the context for the mustache template - and any public properties or methods which accept no arguments will be available to the template. $OUTPUT has several useful public methods which accept no arguments and is a valuable class when creating a layout template in mustache.

The mustache template for this layout is shown here:

''theme/boost/templates/columns1.mustache''
<code handlebars>
{{{ output.doctype }}}
<html {{{ output.htmlattributes }}}>
<head>
<title>{{{ output.page_title }}}</title>
<link rel="shortcut icon" href="{{{ output.favicon }}}" />
{{{ output.standard_head_html }}}
<meta name="viewport" content="width=device-width, initial-scale=1.0">
</head>

<body {{{ bodyattributes }}}>

<div id="page-wrapper">

{{{ output.standard_top_of_body_html }}}

<div id="page" class="container-fluid">
<div id="page-content" class="row">
<div id="region-main-box" class="col-xs-12">
<section id="region-main">
<div class="card card-block">
{{{ output.course_content_header }}}
{{{ output.main_content }}}
{{{ output.course_content_footer }}}
</div>
</section>
</div>
</div>
</div>
</div>
{{{ output.standard_end_of_body_html }}}
</body>
</html>
{{#js}}
require(['theme_boost/loader']);
{{/js}}
</code>

Explaining each line of this template will answer a lot of questions. This example contains only the very minimal required functions to generate a valid layout. You should consider all of the sections below as required in every layout file (although any of the HTML tags can and should be altered).

<code handlebars>
{{{ output.doctype }}}
</code>

This is an example of calling a function on $OUTPUT in php. Because there is a public method on the output class named "doctype" which accepts no arguments - mustache will call it and return the output. We call a function to generate the doctype tag because calling this function returns us the correct HTML for the document type for this theme AND it sets a different content type header (including the charset) depending on the doc type for the theme. Setting a correct charset in every page is important to prevent a class of XSS attacks.

<code handlebars>
<html {{{ output.htmlattributes }}}>
</code>

Now we have returned our root tag - the html tag. We included a set of default attributes for the page by calling the htmlattributes function of our output class. This includes the correct language attribute for the entire page and can include an xml namespace for XHTML documents.

<code handlebars>
<head>
<title>{{{ output.page_title }}}</title>
</code>

Now we have started the head section of our document and set the title for the page. Notice the title is already escaped by the output class so we are using triple mustache tags "{{{" to avoid double escaping.

<code handlebars>
<link rel="shortcut icon" href="{{{ output.favicon }}}" />
</code>

We call a function to get the url to the favicon. The favicon is a file in the theme pix directory and it is served through the "theme/image.php" file which adds special caching headers for images.

<code handlebars>
{{{ output.standard_head_html }}}
</code>

The standard head html function performs a lot of setup that is required for our page. It internally creates the block regions, creates meta tags including keywords for SEO, initialises the common javascript modules, generates links to the style sheets and injects any additional HTML set by the $CFG->additionalhtmlhead setting.

<code handlebars>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
</head>

</code>

This viewport meta tag is recommended by bootstrap for "proper viewport rendering and touch zooming".

<code handlebars>
<body {{{ bodyattributes }}}>
</code>

The body attributes include the language direction and standard classes for the page.

<code handlebars>

<div id="page-wrapper">

</code>

In the Boost theme we use a page-wrapper div to prevent content from disappearing under the fixed header.

<code handlebars>
{{{ output.standard_top_of_body_html }}}

</code>

The standard_top_of_body_html should be included in every layout and includes skip links for accessibility as well as initialising jquery, yui and our own static javascript files.

<code handlebars>
<div id="page" class="container-fluid">
<div id="page-content" class="row">
<div id="region-main-box" class="col-xs-12">
<section id="region-main">
<div class="card card-block">
</code>

This is standard HTML tags defining the content region for this page. The classes come from bootstrap 4.

<code handlebars>
{{{ output.course_content_header }}}
</code>

The course content header allows Moodle plugins to inject things in the top of the page. This is used for "notifications" for example (which are the alert boxes you see after submitting a form).

<code handlebars>
{{{ output.main_content }}}
</code>

The main content function returns the real content for the page.

<code handlebars>
{{{ output.course_content_footer }}}
</code>

The course content footer is used mainly by course formats to insert things after the main content.

<code handlebars>
</div>
</section>
</div>
</div>
</div>
</div>
</code>

We close all our open tags...

<code handlebars>
{{{ output.standard_end_of_body_html }}}
</code>

This function will add all of the javascript that was required while rendering the page. Javascript is added at the end of the document so that it does not block rendering the page.
<code handlebars>
</body>
</html>
</code>

We finish the HTML for our page.
<code handlebars>
{{#js}}
require(['theme_boost/loader']);
{{/js}}
</code>

This final section is required for bootstrap 4 themes and loads all the Bootstrap 4 Javascript dependencies.

If we had block regions in this layout we would need to insert them in the template. The way we would do this is by getting the HTML for the block region in our layout php file, adding it to the context and then including it in our template.

''theme/boost/layout/columns2.php''
<code php>
...
$blockshtml = $OUTPUT->blocks('side-pre');
$hasblocks = strpos($blockshtml, 'data-block=') !== false;
...
$templatecontext = [
...
'sidepreblocks' => $blockshtml,
'hasblocks' => $hasblocks,
...
];
...
echo $OUTPUT->render_from_template('theme_boost/columns2', $templatecontext);
</code>

''theme/boost/templates/columns2.mustache''
<code handlebars>
...
{{#hasblocks}}
<section data-region="blocks-column" class="hidden-print">
{{{ sidepreblocks }}}
</section>
{{/hasblocks}}
...
</code>

When writing layout files think about the different layouts and how the HTML that each makes use of will differ. You will most likely find you do not need a different layout file for each layout, most likely you will be able to reuse the layout files you create across several layouts. You can of course make use of layout options as well to further reduce the number of layout files you need to produce.

Of course as mentioned above if you are customising an existing theme then you may not need to create any layouts or layout files at all.

==Language File==

You need to create a language file for your theme with a few standard strings in it. At a minimum create a file called lang/en/theme_themename.php in your theme folder. For example, the 'boost' theme has a language file called lang/en/theme_boost.php.

You '''must''' define the following lines in your file (example is from Boost theme, adapt as required):

<code php>
$string['pluginname'] = 'Boost';
$string['region-side-pre'] = 'Right';
$string['choosereadme'] = 'Boost is a modern highly-customisable theme. This theme is intended to be used directly, or as a parent theme when creating new themes utilising Bootstrap 4.';
</code>

Without the above you will get notices for the missing strings.

==Making use of images==
Right at the start when listing the features of the new themes system one of the features mentioned was the ability to override any of the standard images within Moodle from within your theme. At this point we will look at both how to make use of your own images within your theme, and secondly how to override the images being used by Moodle.
So first up a bit about images within Moodle,

# Images you want to use within your theme '''need''' to be located within your theme's pix directory.
# You can use sub directories within the pix directory of your theme.
# Images used by Moodle's core are located within the pix directory of Moodle.
# Modules, blocks and other plugins should also store their images within a pix directory.

So making use of your own images first up. Lets assume you have added two image files to the pix directory of your theme.

* /theme/yourthemename/pix/imageone.jpg
* /theme/yourthemename/pix/subdir/imagetwo.png

Notice that one image is a JPEG image, and the second is a PNG. Also the second image is in a subdirectory.

The following code snippet illustrates how to make use of your images within your layout file so they can be inserted by your layout template.
''theme/yourtheme/layout/somelayout.php''
<code php>
...
$templatecontext = [
...
$imageone => $OUTPUT->pix_url('imageone', 'theme'),
$imagetwo => $OUTPUT->pix_url('subdir/imagetwo', 'theme'),
...
];

echo $OUTPUT->render_from_template('theme_yourtheme/somelayout', $templatecontext);
</code>

We use a method of Moodle's output library to generate the URL to the image. Its not too important how that functions works but it is important that we use it as it is what allows images within Moodle to be over-rideable.
'''DO NOT''' include the image file extension. Moodle will work it out automatically and it will not work if you do include it.

''theme/yourtheme/templates/somelayout.mustache''
<code handlebars>
...
<img src="{{{imageone}}}" alt="Please give your image alt text or set the role to presentation" width="50" height="50">
<img src="{{{imagetwo}}}" alt="Please give your image alt text or set the role to presentation" width="50" height="50">
...
</code>

The following is how you would use the images from within CSS, SCSS or Less as background images.

<code css>
.divone {
background-image: url([[pix:theme|imageone]]);
}

.divtwo {
background-image: url([[pix:theme|subdir/imagetwo]]);
}
</code>

If this case we have to use some special notations that Moodle looks for. Whenever Moodle hands out a CSS file it first searches for all ''[[something]]'' tags and replaces them with what is required.

The final thing to notice with both of the cases above is that at no point do we include the images file extension.
The reason for this leads us into the next topic, how to override images.

From within a theme you can VERY easily override any standard image within Moodle by simply adding the replacement image to the theme's pix directory in the same sub directory structure as it is in Moodle.
So for instance we wanted to override the following two images:
# /pix/moodlelogo.gif
# /pix/i/user.gif
We would simply need to add our replacement images to the theme in the following locations
# /theme/themename/pix_core/moodlelogo.gif
# /theme/themename/pix_core/i/user.gif
''Note that we have created a '''pix_core''' directory in our theme. For a specific activity module like chat we need a '''pix_plugins/mod/chat''' directory. This directory is "pix_plugins" and then the plugin type (mod) and then the plugin name (chat).

Now the other very cool thing to mention is that Moodle looks for not just replacements of the same image type (jpg, gif, etc...) but also replacements in any image format. This is why above when working with our images we never specified the images file extension.
This means that the following would also work:
# /theme/themename/pix_core/moodlelogo.png
# /theme/themename/pix_core/i/user.bmp

For a more detailed description of how this all works see the page on [[Using images in a theme]].

==Adding custom fonts==
{{Moodle 2.6}}

CSS3 standard introduced the possibility to specify custom fonts, see [http://www.w3schools.com/css/css3_fonts.asp CSS3 Fonts tutorial].

Since 2.6 Moodle includes support for plugin or theme fonts. It is very similar to theme images and pix subdirectories.

===Font file locations===

Depending on where you intend to use the font put it into one of the following locations:
* /lib/fonts/ - fonts used in core
* /plugindir/fonts/ - fonts used by plugin
* /theme/sometheme/fonts/ - theme specific fonts

You can also override core and plugin fonts in theme:
* /theme/sometheme/fonts_core/ - overridden core fonts
* /theme/sometheme/fonts_plugins/plugintype_pluginname/ - overridden fonts of some plugin

Notes:
* subdirectories are not allowed
* use only lowercase alphanumeric characters and underscore in font file names
* WOFF (Web Open Font Format), TTF (True Type Fonts), OTF (OpenType Fonts), SVG (Scalable Vector Graphic) and EOT (Embedded OpenType) fonts are supported, but for the sake of humanity (And [https://tracker.moodle.org/browse/MDL-15169 MDL_15169] ) please use only WOFF fonts to encourage the quick death of IE8.

===CSS placeholders===

<code css>
@font-face {
font-family: ThreeDumb;
src: url([[font:mod_book|3dumb.woff]]);
}
</code>

The placeholder references file /mod/book/fonts/3dumb.woff, the new fontface could be for example used for book headings:

<code css>
.path-mod-book .book_chapter_title {
font-family: ThreeDumb;
}
</code>

If you want to use some font in theme only, you can for example:

<code css>
@font-face {
font-family: goodDogFont;
src: url([[font:theme|good_dog.woff]]);
}

a {font-family:goodDogFont;}
</code>

The font would be stored in /theme/yourtheme/fonts/good_dog.woff file.

===More free fonts===

Please respect all licenses for font redistribution, you can get some nice free fonts from [http://www.fontsquirrel.com http://www.fontsquirrel.com] for example.

===Warning===

This is not intended for forcing of something like Comic Sans on all your visitors...

==Compiling LESS on the fly==
{{Moodle 2.7}}

You can now provide a LESS file that will be compiled (and cached) on the fly. The purpose of this feature is to dynamically allow the customisation of LESS variables.

===Set up your theme===

# Create a .less file in a less folder. Eg. <code>theme/yourtheme/less/myfile.less</code>
# Edit your theme config file, and set $THEME->'''lessfile''' to the name of your file (do not include .less). Eg. <code>$THEME->lessfile = 'myfile'</code>

That's it, the LESS file will be compiled and included in the page on the fly, but that is not very useful yet.

Please note that any file referenced in $THEME->sheets that shares the same name than the LESS file will be silently ignored.

===Inheriting from a parent===

Even if your theme is inheriting from a parent, the LESS file itself will not inherit from anything, this is something you should do manually. For instance, if you want your LESS file to include all of the LESS code provided by ''theme_bootstrapbase'', usually to change the variables, you need to manually import the file like this:

<code>
@import "../../bootstrapbase/less/moodle.less";
</code>

The path needs to be relative and not absolute. You would definitely want to add that rule first in your file and add anything else below it.

===Programmatically injecting LESS===

There are two theme options to specify a callback function that you need to know about:

# $THEME->'''extralesscallback''': To return raw LESS code to be injected.
# $THEME->'''lessvariablescallback''': To return an array of variables and their values.

Typically you will want to simply inject variables, but if you need to perform more complex manipulations, you can return some raw LESS code. The variables returned by the callback are always injected last.

===Performance===

Compiling LESS on the fly is a slow operation, and even though the result is cached you should be aware of it. If you have enabled the configuration setting ''themedesignermode'' you will definintely notice the slowness as the cache only lives for a very short period of time. Ideally your theme should precompile the LESS into CSS, but if you want to provide theme settings to your user, then using this feature is for you.

===Example===

You can refer to the theme ''theme_more'' for an example on how to use this feature.

==Compiling SCSS on the fly==
{{Moodle 3.2}}

You can now provide a SCSS file that will be compiled (and cached) on the fly. The purpose of this feature is to dynamically allow the customisation of SCSS variables. See the [[SCSS|dedicated page on SCSS]].

==Unobvious Things==
===Getting Your Theme to Appear Correctly in Theme Selector===
If you follow the examples on this page to the letter, when you go to the Theme Selector page you may be discouraged to find that your theme does not appear like the other themes do. In fact, instead of your theme's name, you will see something along the lines of <nowiki>[[pluginname]]</nowiki>.

To correct this, you must add the theme/THEMENAME/lang/en/theme_THEMENAME.php file, where THEMENAME is the name of the theme folder. Inside that file, add the string "$string['pluginname'] = 'THEMENAME'; ". Make THEMENAME the name of your theme, however you want it displayed in the Theme selector.

Also, make sure to change your config.php file and version.php file to reflect the correct name:

In config.php: $THEME->name = 'NAME';

In version.php: $plugin->component = 'theme_NAME'; // Full name of the plugin (used for diagnostics)

The screenshot for the theme should be about 500x400 px.

===Required theme divs===

Some parts of Moodle may rely on particular divs, for example the div with id 'page-header'.

Consequently all themes must include at least the divs (with the same ids) that are present in the 'boost' theme.

Missing out these elements may result in unexpected behaviour within specific modules or other plugins.

==Caching==
When Moodle is not running in theme designer mode it will look for a cached version of the compiled CSS for the current theme to serve to the browser requesting the page. If the cached file doesn't yet exist then the CSS will be built and cached during the page request.

The cached CSS is located on disk in Moodle's local cache:
<Moodle data directory >/localcache/theme/<global theme revision>/<theme_name>/css/all_<theme subrevision>.css

The cache path consists of a global theme revision (themerev config value) and a per theme subrevision (themesubrev plugin config value). If either of those are incremented it will change the path to the cache file and cause a new file to be generated.

Individual theme's CSS cache can be built by using the admin CLI script:
php admin/cli/build_theme_css.php --themes boost

The script will only increment the theme subrevision of the theme(s) being built which means existing theme cache's remain untouched.

==Appendix A==
=== Theme options ===

{| class="nicetable" id="theme_options_table"
|-
! Setting
! Effect
|-
| $THEME->'''blockrtlmanipulations'''
| Allows the theme to manipulate how the blocks are displayed in a ''right-to-left'' language. Not recommended since we automatically flip CSS for rtl.
|-
| $THEME->'''csspostprocess'''
| Allows the user to provide the name of a function that all CSS should be passed to before being delivered.
|-
| $THEME->'''csstreepostprocessor''' (Since 3.2)
| Allows the user to provide the name of a function that can perform manipulations on an in-memory representation of the CSS tree. Some useful manipulations are available such as the "theme_boost\autoprefixer" which will automatically add vendor prefixes to all CSS that requires them.
|-
| $THEME->'''doctype'''
| The doctype of the served documents.
|-
| $THEME->'''editor_sheets'''
| An array of stylesheets to include just within the body of the TinyMCE text editor. This is required if you want content to resemble its final appearance in the page, while it is being edited in the text editor.
|-
| $THEME->'''enablecourseajax'''
| If set to false the course AJAX features will be disabled.
|-
| $THEME->'''enable_dock'''
| If set to true the side dock is enabled for blocks.
|-
| $THEME->'''prescsscallback'''
| The name of a function that will return some SCSS code to inject at the beginning of the SCSS file specified in $THEME->scss. (Since 3.2)
|-
| $THEME->'''extrascsscallback'''
| The name of a function that will return some SCSS code to inject at the end of the SCSS file specified in $THEME->scss. (Since 3.2)
|-
| $THEME->'''extralesscallback'''
| The name of a function that will return some LESS code to inject at the end of the LESS file specified in $THEME->lessfile. (Since 2.7)
|-
| $THEME->'''hidefromselector'''
| Used to hide a theme from the theme selector (unless theme designer mode is on). Accepts true or false.
|-
| $THEME->'''javascripts'''
| An array containing the names of JavaScript files located in /javascript/ to include in the theme. (gets included in the head). This setting should no longer be used - please use AMD [[Javascript Modules]] instead.
|-
| $THEME->'''javascripts_footer'''
| As above but will be included in the page footer. This setting should no longer be used - please use AMD [[Javascript Modules]] instead.
|-
| $THEME->'''layouts'''
| An array setting the layouts for the theme
|-
| $THEME->'''lessfile'''
| The name of a LESS file in the theme's less/ folder to compile on the fly. Sheets with the same name will be ignored. (Since 2.7)
|-
| $THEME->'''lessvariablescallback'''
| The name of a function that will modify some LESS variables before compiling the LESS file specified in $THEME->lessfile. (Since 2.7)
|-
| $THEME->'''scss'''
| The name of a SCSS file in the theme's scss/ folder to compile on the fly. Sheets with the same name will be ignored. This can also be a function which returns SCSS, in which case all import paths will be relative to the scss folder in this theme or any of it's parents. (Since 3.2)
|-
| $THEME->'''name'''
| Name of the theme. Most likely the name of the directory in which this file resides.
|-
| $THEME->'''parents'''
| An array of themes to inherit from. If the theme you inherit from inherits from a parent as well, you need to indicate the grand parent here too.
|-
| $THEME->'''parents_exclude_javascripts'''
| An array of JavaScript files NOT to inherit from the themes parents
|-
| $THEME->'''parents_exclude_sheets'''
| An array of stylesheets not to inherit from the themes parents
|-
| $THEME->'''plugins_exclude_sheets'''
| An array of plugin sheets to ignore and not include.
|-
| $THEME->'''renderfactory'''
| Sets a custom render factory to use with the theme, used when working with custom renderers. You most likely want this set to "theme_overridden_renderer_factory".
|-
| $THEME->'''sheets'''
| An array of stylesheets to include for this theme. Should be located in the theme's style directory. Not required if using less or scss.
|-
| $THEME->'''yuicssmodules'''
| An array of YUI CSS modules to be included. This setting should probably be set to '' to prevent and YUI CSS being included.
|-
| $THEME->'''undeletableblocktypes'''
| An array of Block types that must exist on all pages in this theme or this theme will be unusable. If a block type listed here is missing when a page is loaded - it will be auto-created (but only shown for themes that require it).
|-
| $THEME->'''addblockposition'''
| Either BLOCK_ADDBLOCK_POSITION_FLATNAV, BLOCK_ADDBLOCK_POSITION_DEFAULT or BLOCK_ADDBLOCK_POSITION_CUSTOM. Defines where to put the "Add a block" controls when editing is enabled.
|}

===The different layouts as of 21st April 2013===
{| class="nicetable" id="theme_layouts_table"
|-
! Layout
! Purpose
|-
| base
| Most backwards compatible layout without the blocks - this is the layout used by default.
|-
| standard
| Standard layout with blocks, this is recommended for most pages with general information.
|-
| course
| Main course page.
|-
| coursecategory
| Use for browsing through course categories.
|-
| incourse
| Default layout while browsing a course, typical for modules.
|-
| frontpage
| The site home page.
|-
| admin
| Administration pages and scripts.
|-
| mydashboard
| My dashboard page.
|-
| mypublic
| My public page.
|-
| login
| The login page.
|-
| popup
| Pages that appear in pop-up windows - no navigation, no blocks, no header.
|-
| frametop
| Used for legacy frame layouts only. No blocks and minimal footer.
|-
| embedded
| Used for embedded pages, like iframe/object embedded in moodleform - it needs as much space as possible
|-
| maintenance
| Used during upgrade and install. This must not have any blocks, and it is a good idea if it does not have links to other places - for example there should not be a home link in the footer.
|-
| print
| Used when the page is being displayed specifically for printing.
|-
| redirect
| Used when a redirection is occurring
|-
| report
| Used for reports.
|-
| secure
| Used for safebrowser and securewindow.
|}

==See also==
* MoodleBites Theme Design - completely online courses [https://www.moodlebites.com/mod/page/view.php?id=3208 Level 1] and [https://www.moodlebites.com/mod/page/view.php?id=3210 Level 2] are designed to assist Moodle administrators, designers, and developers get up-to-speed with Moodle Theme design, and are run by [https://www.hrdnz.com HRDNZ] (Certified Moodle Partner since 2006).

[[Category:Plugins]]

Tutorial

2019-02-05T03:08:22Z

Stuartrmealor: /* See also */

Welcome to Moodle development!

This is a tutorial to help you learn how to write plugins for Moodle from start to finish, while showing you how to navigate the most important developer documentation along the way.

PRE-REQUISITES: We assume you are fairly comfortable with [[PHP FAQ|PHP]] in general and that you are able to [[:en:Installing AMP|install a database and web server]] on your local machine.

If you need to learn PHP, you can see one PHP tutorial at http://www.w3schools.com/php/default.asp, another at http://php.net/manual/en/tutorial.php and several videos in YouTube at https://www.youtube.com/results?search_query=learn+php.

==Background==
===What's in the box===
If you [http://download.moodle.org/ download] Moodle source code or clone it from [https://github.com/moodle/moodle git], you will see a bunch of files and folders. This code consists of [[Core_APIs|Moodle core]] (that consists of the Very core and Core components), [[Moodle_libraries_credits|third party libraries]] and [[Plugin_types|plugins]]. Their mixed locations can be quite confusing at first but as you start working with it it will become more clear. Moodle developers should avoid modifications of the third party libraries (unless required) and core can never call methods defined in plugins. See also [[Communication Between Components]]

===Setting up your development environment===
* [[Setting up development environment]]: PHP server, database...
* Moodle uses Git for development. View the following link for basic information about Git and Moodle: [[Git for developers]]

===The Moodle development framework===
===What type of plugin are you developing?===
* Moodle has lots of different types of plugins.
* There are 24 different categories of plugin listed on the moodle plugin database. Before starting check here to see if someone else has not already created what you are looking for. Perhaps you could contribute to their plugin instead of creating a new one.

links

* https://moodle.org/plugins/
* [[Plugin types]]

==Let's make a plugin==
===The skeleton of your plugin===

The code of a plugin is organised into multiple different files and directories within a single root directory. All plugins follow the same directory and file structure.

Links

* [[Plugin files]] - Provides a list of required and common plugins files along with their location and purpose.

===Basic page structure===

The link below explains how to create and display a simple page in Moodle.

links

* [[Page API]]

===Multiple languages support===
Moodle has a mechanism for displaying given text string in multiple languages, depending on the user's preferred language and the site configuration. Plugin authors must define all the text strings used by the plugin in the default English language. That is then used as a reference for translations to other languages.

* [[String API]]

===Moodle file structure===
==== Automatic Class Loading ====
Automatic class loading helps us to automatically include class files as and when they are required instead of manually including them everytime. Moodle supports automatic class loading. See the link below for the explanation of rules associated with it -

links

[[ Automatic class loading]]

==== Callbacks ====
You can add a lot of features to your plugin by providing certain callbacks that Moodle expects to be present in your plugin's lib.php file. A detailed list can be found at -

links

[[ Callbacks ]]

==== Plugin types ====
Moodle supports a wide range of plugin types. The complete list and location to place these plugins can be found at -

links

[[ Plugin types ]]

==== Core APIs ====
Moodle provides apis for a plugin to interact with core and other external systems. For example you don't have to manually do any SQL queries, Moodle provides it's own DDL and DML layers. The link below lists all major core apis in Moodle -

links

[[ Core APIs ]]

==== Browser accessible pages ====
Any php file in your plugin will either be browser accessible or be an internal file.

For browser accessible pages you must include config.php with code something similar to this -
<code php>
require_once('../../config.php');
</code>

For internal files the code should use the following -
<code php>
defined('MOODLE_INTERNAL') || die();
</code>

===Add basic content to your page===
* Content for a page is added through renderers.
* Renderers are typically stored in the "classes/output" directory.
* Putting content in renderers allows themers to override the visual display of the content.
* Very basic information is presented using the html_writer class.

links

* [[Renderer]]

=== Content with templates ===
* In most cases when displaying content, templates should be used.
* templates are stored in the "templates" directory. The templates use mustache files.
* Mustache files allow for more generic html with placeholders inserted, that inserts the data (context) at run time.

links

* [[Templates]]

===Adding your plugin into Moodle's navigation===
* The moodle navigation system has hooks which allows plugins to add links to the navigation menu.
* Hooks are located in lib.php. Try to keep lib.php as small as possible as this file is included on every page. Put classes and functions elsewhere.
* Course navigation extension example:
<code php>
function tool_devcourse_extend_navigation_course($navigation, $course, $coursecontext) {
$url = new moodle_url('/admin/tool/devcourse/index.php');
$devcoursenode = navigation_node::create('Development course', $url, navigation_node::TYPE_CUSTOM, 'Dev course', 'devcourse');
$navigation->add_node($devcoursenode);
}
</code>

links

* [[Navigation API]]
* [[:en:Navigation]]

===Database queries===
* Moodle has a generic database query library. Behind this library are additional libraries which allow Moodle to work with MySQL, PostgreSQL, Oracle, SQL Server, and Maria DB.
* Where possible it is advisable to use the predefined functions rather than write out SQL. Writing SQL has a greater chance of not working with one of the supported databases.
* The return of the select functions tends to be an object or an array of objects.

Example call to retrieve data from the course table.
<code php>
global $DB;
$courses = $DB->get_records('course', null, '', 'id, category, fullname, shortname');
</code>
Example of data returned from the above code.
<code>
Array
(
[43] => stdClass Object
(
[id] => 43
[category] => 1
[fullname] => XX -Test 5
[shortname] => xxt5
)

[5] => stdClass Object
(
[id] => 5
[category] => 1
[fullname] => With the glossary
[shortname] => wtg
)

[39] => stdClass Object
(
[id] => 39
[category] => 1
[fullname] => XX - Test 1
[shortname] => xxt1
)
)
</code>

links

* [[Database]]
* [[Data manipulation API]]

===Creating your own database tables===
* We create our database tables in Moodle using the XMLDB editor. This is located in the administration block "Site administration | Development | XMLDB editor".
* The {plugin}\db directory needs to have write access for the XMLDB editor to be most effective.
* XMLDB editor creates an install.xml file in the db directory. This file will be loaded during the install to create your tables.
* XMLDB editor will produce php update code for adding and updating moodle database tables.

The XMLDB main page.

[[{{ns:file}}:xmldb-main.png]]

Upgrade code generated by the XMLDB

[[{{ns:file}}:xmldb-upgrade-code.png]]

links
* [[XMLDB editor]]
* [[Using XMLDB]]
* [[XMLDB Documentation]]
* [[Upgrade API]]
* [[XMLDB introduction]]

===Supporting access permissions: roles, capabilities and contexts===
* Capabilities are controlled in "access.php" under the "db" directory.
* This file has an array of capabilities with the following:
** name
** possible security risks behind giving this capability.
** The context that this capability works in.
** The default roles (teacher, manager, student, etc) that have this capability.
** Various other information.
* These capabilities are checked in code to allow access to pages, sections, and abilities (saving, deleting, etc).

links
* [[Access API]]
* [[Roles#Context]]
* [[:en:Category:Capabilities]]
* [[:en:Roles and permissions]]

===Adding web forms===
* Moodle has it's own forms library.
* The forms lib includes a lot of accessibility code, and error checking, by default.
* Moodle forms can be displayed in JavaScript using 'fragments'.

links

* [[Form API]]
* [[lib/formslib.php Form Definition]]
* [[Fragment]]

===Maintaining good security===
* Use the sesskey when directing to pages to do actions.
* Use the appropriate filters when retrieving parameters

links

* [[Security]]
* [[lib/formslib.php Form Definition#Most Commonly Used PARAM .2A Types]]
* [[Output functions#p.28.29 and s.28.29]]

===Handling files===
* Files are conceptually stored in file areas.
* Plugins can only access files from it's own component.

links

* [[File API]]
* [[File API internals]]
* [[Using the File API in Moodle forms]]

===Adding Javascript===
* Moodle is currently using jquery and AMD (Asynchronous Module Definition).
* JavaScript files are located in the "amd/src" directory.
* Use grunt to build your JavaScript.
* Include your JavaScript in php files as follows:
<code php>
$this->page->requires->js_call_amd('{JScriptfilename}');
</code>
* Can also be included in mustache templates.

links

* [[Javascript Modules]]
* [[jQuery]]
* [[Javascript FAQ]]
* [[JavaScript guidelines]]
* [[Grunt]]

===Adding events and logging===
* All logging in moodle is done through the events system.
* New events should be located in the "classes/event" directory.
* It is possible to create observers and subscribe to events.

links

* [[Event 2]]
* [[Logging 2]]

===Accessibility===

Accessibility is an important consideration while developing a plugin to make sure your plugin is accessible to all users and doesn't discriminate against users with disablities. This often is a mandated requirement in many countries. The links below explain common practices that we follow at Moodle to make the interface more accessible.

links
* [[Accessibility]]
* [[Usability]]
===Web Services and AJAX===
* Moodle web services uses the external functions API.
* The recommended way to make AJAX requests is to use the ajax AMD file which uses the external functions API.
* External functions should be located in the "classes/external.php" file.
* A list of services should be included in "db/services.php". This file is required to register the web services with Moodle.
* The services list is an array which contains:
** '''classname''' Name of the external class.
** '''methodname''' The name of the external function.
** '''classpath''' system path to the external function file.
** '''description''' Description of the function
** '''type''' Create, read, update, delete
** '''ajax''' Can this function be used with ajax?
** '''capabilities''' Capabilities required to use this function.

links

* [[External functions API]]
* [[Adding a web service to a plugin]]
* [[Web services API]]

===Using caching to improve performance===
* The main cache used by moodle is the Moodle Universal Cache (MUC).
* The MUC has several cache definitions -
** Request cache
** Session cache
** Application

links

* [[The Moodle Universal Cache (MUC)]]
* [[:en:MUC FAQ]]
* [[:en:Caching]]

===Supporting backup and restore===
* Supporting backup and restore requires creating several files in the 'backup/moodle2' directory.
* Back requires a class to extend the backup_task of some sort. There may be a specific plugin task to extend.
* Restore requires a class to extend the restore_task of some sort. There may be a specific plugin task to extend.
* The restore steps lib defines the structure of the plugin to be restored.
* The backup steps lib defines steps, settings, attributes, etc.

links

* [[Backup 2.0 for developers]] - provides an example of step-by-step implementation of backup support to your plugin
* [[:en:Backup and restore FAQ]]

===Supporting automated testing===
* Moodle has two types of automated testing: php unit tests, and behat tests.
* Unit tests are for testing functions.
* Behat tests runs through scenarios.
** Behat tests follows a script and navigates through moodle pages.
* unit tests should be located in the "tests" directory.
* behat tests should be located in the "tests/behat" directory.
* Tests located in these directories will be run through when a full test run is initiated.
* behat tests are actually feature files and end with the extension ".feature".

links

* [[Writing PHPUnit tests]]
* [[PHPUnit]]
* [[Acceptance testing]]
* [[Behat integration]]

==Publishing your plugin==
===Adding your plugin to moodle.org===
* publish your plugins at https://moodle.org/plugins/
* Publishing plugins on the moodle site leads you through a bunch of steps that need to be completed in order for the plugin to be approved and published.
* Plugins will be run through a pre-checker to give suggestions about possible issues with the code.

===Supporting your plugin===

==TODO==
Finishing this tutorial:
# About one or two screens for each section with a very generic overview for beginners, containing links to relevant docs WITH COMMENTS ABOUT QUALITY, USEFULNESS, CAVEATS etc.
# Go through all the linked pages and make sure they are current and accurate.
# Add a worked example to this page, so that each section has suggestions about things to add to the admin tool being built as an exercise. If the code is long, it could be placed on separate pages. A good reference for style is [[Mobile_support_for_plugins]] and [[Blocks]].

==See also==
* See [https://moodle.org/mod/forum/discuss.php?d=355789 this (july 2017) forum thread ] about Getting Started with Moodle Development.
* See [https://moodle.org/mod/forum/discuss.php?d=352360 this (may 2017) forum thread] about Getting Started with Moodle Development.
* MoodleBites for Developers - completely online courses [https://www.moodlebites.com/mod/page/view.php?id=24546 Level 1] and [https://www.moodlebites.com/mod/page/view.php?id=19542 Level 2] are designed to get new developers up-to-speed with Moodle development, and are run online by HRDNZ (Certified Moodle Partner since 2006).

See also these older tutorials:

* [[Blocks|A Step-by-step Guide To Creating Blocks]]
* [[NEWMODULE Tutorial]]
* [[Mobile_support_for_plugins|Moodle Mobile plugin tutorial]]
* [[Category:Tutorial|Other tutorials in these docs]]

==Any questions?==

If you have any questions, you're welcome to post in the [https://moodle.org/mod/forum/view.php?id=55 General developer forum] on moodle.org

[[Category:Tutorial]]

Developer FAQ

2019-02-05T03:04:25Z

Stuartrmealor: /* Where can I start? */

==Help for new coders==

===Where can I start?===

* [[Finding your way into the Moodle code]]
* [http://dev.moodle.org/ Moodle Developer Courses]
* MoodleBites for Developers online courses [https://www.moodlebites.com/mod/page/view.php?id=24546 Level 1] and [https://www.moodlebites.com/mod/page/view.php?id=19542 Level 2]

===Where can "newbies" to Moodle get help?===

The [http://moodle.org/mod/forum/view.php?f=33 General developer forum]! Feel free to ask any question, no matter how basic or advanced. Many people ask different levels of question every day, and the community is generally welcoming and quick to respond.

===How do I create a patch?===

See [[How to create a patch]].

=== How do I create a new module or plugin? ===

See
* [[NEWMODULE Documentation]]
* [[Blocks]]
* [[Authentication plugins]]
* [[Developer_documentation#Make_a_new_plugin|full list of plugin types]].
* Also have a look at the [http://dev.moodle.org/ Moodle Developer Courses].

; Book
: [https://www.packtpub.com/moodle-1-9-extension-development/book Moodle 1.9 Extension Development - Customize and extend Moodle using its robust plug-in systems] by Jonathan Moore, Michael Churchward - highly recommended

===Is there any information on backup and restore?===

See [[Backup]].

==I can't use one of the available plug-in points to make my change. What alternative is there?==

See [[Local customisation]].

==Moodle's database==

===Where can I see a schema for the structure of the Moodle database?===

[[Database_schema_introduction]] gives a high level overview of the database schema.

Because of Moodle's modular nature, there is no single, detailed representation of the full database schema. Instead, the tables for each part of Moodle are defined in a database-neutral XML format, see [[Database_FAQ#XMLDB| XMLDB]], in each part of Moodle. Look for files called install.xml in folders called db throughout the code. Alternatively, from Moodle 2.0 onwards, go to Administration -> Development -> XMLDB editor, and use the [Doc] links to see automatically generated documentation built form the comments in the install.xml files.

See also [[Database FAQ]].

==How to get/set information when writing new Moodle code==

===How do I find out the currently-logged-on user?===

The global object $USER, which contains the numeric $USER->id among other things.

===How do I find out the current course?===
The global object $COURSE, which contains the numeric $COURSE->id

===How do I insert/retrieve records in the database, without creating my own database connections?===

You use the $DB object, as described in the [[Data manipulation API]] documentation.

===How do I get/set configuration settings?===

;config table
To get config values you would typically access the global $CFG object directly, which is automatically created by the core Moodle scripts. To set these "main" config values use ''set_config($name, $value)''. The values are stored in the Moodle "config" database table, but these functions take care of cacheing on your behalf, so you should always use these rather than fetching the records directly.

;config_plugin table
There is also a second table of config settings specifically for plugins ("config_plugin"). These are not automatically loaded into the $CFG object, so to fetch these you would use get_config($plugin, $name). To set them use set_config($name, $value, $plugin).

On top of those global configuration values, individual blocks may also have configuration "object" associated with it (the data is serialized and stored in the "block_instance" table). Within blocks, this data is automatically loaded into the <tt>config</tt> attribute of the block.

==What is 'HEAD'?==

HEAD is version control jargon for the latest version, so at the moment it means Moodle 2.0 dev version. (After the Moodle 2.0 stable branch is made, HEAD will mean 2.1 dev). Look for example, at the links at the top of http://cvs.moodle.org/moodle/README.txt?view=log&pathrev=MOODLE_19_STABLE You can get it from http://download.moodle.org/ and install it if you want to play.

== How do I migrate code to Moodle 2.0? ==
* See [[Migrating contrib code to 2.0]]

==See also==

*[[Contributed code FAQ]]
*Using Moodle [http://moodle.org/mod/forum/view.php?f=33 General developer forum]

Using Moodle forum discussions:
*[http://moodle.org/mod/forum/discuss.php?d=55719 How does date / time in DB convert to real Date / Time?]
*[http://moodle.org/mod/forum/discuss.php?d=158521 Why git?]

==Learn more==

*Two online courses specifically for Moodle developers [https://www.moodlebites.com/mod/page/view.php?id=24546 Level 1] and [https://www.moodlebites.com/mod/page/view.php?id=19542 Level 2] are run by [http://www.hrdnz.com HRDNZ] (certified Moodle Partner since 2006) specifically helping new Moodle developers get up-to-speed with Moodle development.

[[Category: FAQ]]

Developer FAQ

2019-02-05T03:00:50Z

Stuartrmealor: /* See also */

==Help for new coders==

===Where can I start?===

* [[Finding your way into the Moodle code]]
* [http://dev.moodle.org/ Moodle Developer Courses]

===Where can "newbies" to Moodle get help?===

The [http://moodle.org/mod/forum/view.php?f=33 General developer forum]! Feel free to ask any question, no matter how basic or advanced. Many people ask different levels of question every day, and the community is generally welcoming and quick to respond.

===How do I create a patch?===

See [[How to create a patch]].

=== How do I create a new module or plugin? ===

See
* [[NEWMODULE Documentation]]
* [[Blocks]]
* [[Authentication plugins]]
* [[Developer_documentation#Make_a_new_plugin|full list of plugin types]].
* Also have a look at the [http://dev.moodle.org/ Moodle Developer Courses].

; Book
: [https://www.packtpub.com/moodle-1-9-extension-development/book Moodle 1.9 Extension Development - Customize and extend Moodle using its robust plug-in systems] by Jonathan Moore, Michael Churchward - highly recommended

===Is there any information on backup and restore?===

See [[Backup]].

==I can't use one of the available plug-in points to make my change. What alternative is there?==

See [[Local customisation]].

==Moodle's database==

===Where can I see a schema for the structure of the Moodle database?===

[[Database_schema_introduction]] gives a high level overview of the database schema.

Because of Moodle's modular nature, there is no single, detailed representation of the full database schema. Instead, the tables for each part of Moodle are defined in a database-neutral XML format, see [[Database_FAQ#XMLDB| XMLDB]], in each part of Moodle. Look for files called install.xml in folders called db throughout the code. Alternatively, from Moodle 2.0 onwards, go to Administration -> Development -> XMLDB editor, and use the [Doc] links to see automatically generated documentation built form the comments in the install.xml files.

See also [[Database FAQ]].

==How to get/set information when writing new Moodle code==

===How do I find out the currently-logged-on user?===

The global object $USER, which contains the numeric $USER->id among other things.

===How do I find out the current course?===
The global object $COURSE, which contains the numeric $COURSE->id

===How do I insert/retrieve records in the database, without creating my own database connections?===

You use the $DB object, as described in the [[Data manipulation API]] documentation.

===How do I get/set configuration settings?===

;config table
To get config values you would typically access the global $CFG object directly, which is automatically created by the core Moodle scripts. To set these "main" config values use ''set_config($name, $value)''. The values are stored in the Moodle "config" database table, but these functions take care of cacheing on your behalf, so you should always use these rather than fetching the records directly.

;config_plugin table
There is also a second table of config settings specifically for plugins ("config_plugin"). These are not automatically loaded into the $CFG object, so to fetch these you would use get_config($plugin, $name). To set them use set_config($name, $value, $plugin).

On top of those global configuration values, individual blocks may also have configuration "object" associated with it (the data is serialized and stored in the "block_instance" table). Within blocks, this data is automatically loaded into the <tt>config</tt> attribute of the block.

==What is 'HEAD'?==

HEAD is version control jargon for the latest version, so at the moment it means Moodle 2.0 dev version. (After the Moodle 2.0 stable branch is made, HEAD will mean 2.1 dev). Look for example, at the links at the top of http://cvs.moodle.org/moodle/README.txt?view=log&pathrev=MOODLE_19_STABLE You can get it from http://download.moodle.org/ and install it if you want to play.

== How do I migrate code to Moodle 2.0? ==
* See [[Migrating contrib code to 2.0]]

==See also==

*[[Contributed code FAQ]]
*Using Moodle [http://moodle.org/mod/forum/view.php?f=33 General developer forum]

Using Moodle forum discussions:
*[http://moodle.org/mod/forum/discuss.php?d=55719 How does date / time in DB convert to real Date / Time?]
*[http://moodle.org/mod/forum/discuss.php?d=158521 Why git?]

==Learn more==

*Two online courses specifically for Moodle developers [https://www.moodlebites.com/mod/page/view.php?id=24546 Level 1] and [https://www.moodlebites.com/mod/page/view.php?id=19542 Level 2] are run by [http://www.hrdnz.com HRDNZ] (certified Moodle Partner since 2006) specifically helping new Moodle developers get up-to-speed with Moodle development.

[[Category: FAQ]]

User talk:Stuart Mealor

2016-03-03T07:56:53Z

Stuartrmealor:

Such a long time since I've edited anything here...
Wow - we're still using such an old looking editor (but it obviously doesn't need Atto or similar for a Wiki.
Anyway, I'm going to start getting into a bit more Moodle development now - not that I will have enough time, or talent, to become of guru :-(

----
Here's our new MoodleBites developer level courses...

MoodleBites for Developers - http://www.moodlebites.com/mod/page/view.php?id=19542

and

MoodleBites Introduction to Moodle Development - http://www.moodlebites.com/mod/page/view.php?id=24546

--[[User:Stuart Mealor|Stuart Mealor]] ([[User talk:Stuart Mealor|talk]]) 15:53, 3 March 2016 (AWST)

User talk:Stuart Mealor

2016-03-03T07:56:09Z

Stuartrmealor:

Such a long time since I've edited anything here...
Wow - we're still using such an old looking editor (but it obviously doesn't need Atto or similar for a Wiki.
Anyway, I'm going to start getting into a bit more Moodle development now - not that I will have enough time, or talent, to become of guru :-(

----
Here's our new MoodleBites developer level courses...

MoodleBites for Developers - http://www.moodlebites.com/mod/page/view.php?id=19542
and
MoodleBites Introduction to Moodle Development - http://www.moodlebites.com/mod/page/view.php?id=24546

--[[User:Stuart Mealor|Stuart Mealor]] ([[User talk:Stuart Mealor|talk]]) 15:53, 3 March 2016 (AWST)

User talk:Stuart Mealor

2016-03-03T07:54:00Z

Stuartrmealor:

Such a long time since I've edited anything here...
Wow - we're still using such an old looking editor (but it obviously doesn't need Atto or similar for a Wiki.
Anyway, I'm going to start getting into a bit more Moodle development now - not that I will have enough time, or talent, to become of guru :-(

----
Here's our new MoodleBites developer level courses...

MoodleBites for Developers - http://www.moodlebites.com/mod/page/view.php?id=19542
and
MoodleBites Introduction to Moodle Development - http://www.moodlebites.com/mod/page/view.php?id=24546
--[[User:Stuart Mealor|Stuart Mealor]] ([[User talk:Stuart Mealor|talk]]) 15:53, 3 March 2016 (AWST)

User talk:Stuart Mealor

2016-03-03T07:46:58Z

Stuartrmealor:

Projects for new developers

2014-02-27T00:56:47Z

Stuartrmealor: /* Plagiarism plugin */

==Getting started==

Moodle uses PHP, JavaScript and a number of other Web languages, so learning those is a good place to start.

When you have some basic PHP programming skills, you may wish to start learning about how to Moodle code is organised. It is recommended that you complete the [http://dev.moodle.org/course/view.php?id=2 Introduction to Moodle Programming] course on [http://dev.moodle.org/ dev.moodle.org]. To access this you will need to have an account on moodle.org first.

''If you are looking for projects suggested in the tracker, look for issues with the [https://tracker.moodle.org/issues/?jql=labels%20in%20%28addon_candidate%29 'addon_candidate' label].

''If you are looking to make a quick contribution, look for tracker issues with marked as [https://tracker.moodle.org/issues/?jql=Difficulty%20%3D%20Easy easy].

As you become more involved in Moodle development, you might like to learn more about the [[Coding|coding conventions]] used and how changes to Moodle core code are [[Process|processed]].

==Potential projects==

This evolving page lists possible Moodle projects for new developers derived from community suggestions.

''If you have any ideas for new features in Moodle which might be suitable as projects for new developers, please see [[New feature ideas]].''

=== SCORM ===

There are various SCORM related projects I'd be interested in mentoring for GSOC in 2014.
* Fix/Improve built in SCORM navigation (MDL-25642 MDL-29193 MDL-39551)
* Improve SCORM performance, PHPDocs, compliance with coding guidelines. - There are a number of known areas of SCORM code that need a clean-up/re-structure - It would be good to audit all the scorm code and make it comply with Moodle's coding guidelines and improve the performance of the code - it would be good to implement MUC in areas that can make use of it - Ideally we would also rewrite the datamodels/scorm_*_.js.php files to separate the php from the js and make the JavaScript cache-able - (work started on this in MDL-35870) Other related bugs: MDL-41216 MDL-41665 MDL-42314
* SCORM reports - there are currently 3 SCORM reports - ideas on new report plugins would be considered as possible projects.

:'''Skills required''': PHP, JavaScript
:'''Difficulty level''': Medium -> Hard
:'''Possible mentor''': [http://moodle.org/user/view.php?id=21591&course=5 Dan Marsden]

===HTML maths editor===

Traditional written mathematical notation takes advantage of a rich set of special symbols, together with their relative size and
position on a two dimensional page. Underlying mathematical expressions is a well-defined semantic tree structure. When typing a mathematical expression into a computer keyboard the ability to take advantage of the features of traditional mathematical notation is severely limited. Essentially one has only a one-dimensional string of symbols taken from the limited alphabet found on computer keyboards and a strict syntax. Syntax is often problematic for users. For example, they differ between applications and they do not correspond to traditional notation.

DragMath (http://www.dragmath.bham.ac.uk) is a nice "drag and drop" equation editor that has been integrated with the Moodle editor for some time. However, it is implemented in Java, and that is becoming increasingly problematic, with increasing security warnings on the desktop, and limited support on mobile devices. We would like a new editor, keeping all the good parts of DragMath, but written in JavaScript. This could then be integrated with Moodle and other web applications.

Goal: to create a useful and usable "mathematics entry system" for Moodle, using a combination of JavaScript and HTML5.

This should
* parse typed expressions into an internal tree representation
* provide useful feedback to users, e.g. "missing bracket", on ill-formed expressions.
* have flexible options for providing a "context" to mediate between the requirements of a strict syntax, and users' expectations based on traditional written mathematics. E.g. is "x(t+1)" a multiplication of x and (t+1) or application of the function "x" to the argument "(t+1)"?
* have "drag and drop" components (in HTML5)
* have a modular and flexible output mechanism, this includes
** on-screen display "as you type/edit"
** output in a variety of formats, LaTeX, Maxima syntax, MathML etc. which can be embedded into web applications, specifically Moodle. It is not a goal to provide multiple outputs, but it is a goal to develop a framework in which other users can contribute such formats.
** show users the internal tree representation on request
* potentially enable manipulation (computer algebra) of internal expressions by pre-defined rules.
* have a well documented and simple API.

Much of the basic design has been done in for example
* DragMath http://www.dragmath.bham.ac.uk/
* Numbas http://www.ncl.ac.uk/maths/numbas/
* CanvasMath https://code.google.com/p/canvasmath/
We will draw from this previous design experience to guide the development.

See this forum thread: https://moodle.org/mod/forum/discuss.php?d=251627 for more.

:'''Skills required''': JavaScript, HTML 5
:'''Difficulty level''': Hard
:'''Possible mentors''': Chris Sangwin

===New question types===

This is not really a specific project idea, but I would like to point one an important general area:

With HTML5 the range of what can be done in a web browser keeps expanding. Can we use these possibilities to make new, much more interactive, question types for Moodle?

There are some ideas in this forum thread: https://moodle.org/mod/forum/discuss.php?d=222439
* a question type where students have to join things up correctly by adding lines to a diagram (for example to complete an electric circuit).
* a question type where students can change the colour of certain parts of a diagram, and they have to get it correct.
* ... I am sure there are more possible ideas. Use your imagination!

There are also some ideas which don't require complex HTML5 things:
* A 'Give 3 examples of ...' Question type. For example "Give three ways to speed up a chemical reaction:". Answer 'heat', 'increase concentration', 'catalyst' (in any order). However, 'warm it' might be an acceptable alternative, but 'heat', 'catalyst', 'warm it' should only score 2/3.
* An ordering question type. Probably based on the OU's qtype_ddwtos. The think that cannot do is give good credit for partially correct answer. For example 'F', 'A', 'B', 'C', 'D', 'E' might be considered close to the right order, but if you do that with ddwtos it will score 0.
* A question type where students must highlight certain words in some text. E.g. "Find all the verbs in this paragraph."

There is also scope to make significant enhancements to existing question types. For example
* in [https://moodle.org/plugins/view.php?plugin=qtype_ddmarker Drag and drop markers] allow teachers to define the drop zones by dragging with the mouse, rather than typing co-ordinates.
* in [https://moodle.org/plugins/view.php?plugin=qtype_pmatch the pattern-match question type] a tool like STACK question tests to help teachers verify that their answer matching works correctly (upload example responses, indicate what grade they should receive, show what grade they actually receive, and highlight the differences.

Before proposing anything, please make sure you are familiar with the [https://docs.moodle.org/22/en/Questions standard question types] already available in Moodle, and the [http://moodle.org/plugins/browse.php?list=category&id=29 contributed question types] that other people have already created.

:'''Skills required''': PHP & JavaScript
:'''Difficulty level''': Medium - Hard
:'''Possible mentors''': Tim Hunt

=== Plagiarism plugin ===

There are various commercial plugins available that use the Plagiarism API in Moodle, but because these plagiarism systems can require paid subscriptions, testing them can be difficult. I'd like to see a basic plugin developed that could be used for testing the Plagiarism API, providing simple useful functionality. All Plagiarism API functions for all Modules that support the API should be implemented and used. It could check the file contenthash against all other files uploaded in the Moodle files table and if a matching record is found it should display information about the duplicate submission including if the same student has submitted the file in a different course/activity or if a different user has uploaded the file with the same contenthash.

The first stage of this project is to implement very simple high performing code that allows easy testing of the Plagiarism API and provide some very basic functionality by checking the contenthash
This code should implement unit tests and behat tests so that we can verify that the Moodle Plagiarism API is functioning correctly.

The long term plan (possibly after GSOC) would be to get this plugin to post content to an external source which could implement a more complete plagiarism check running on a separate server so it doesn't affect performance of the Moodle site. The Plagiarism plugin "Crot" may have some code that could be repurposed to use for this.

:'''Skills required''': PHP
:'''Difficulty level''': Medium
:'''Possible mentor''': [http://moodle.org/user/view.php?id=21591&course=5 Dan Marsden]
:'''Discussion''': [http://dev.moodle.org/mod/forum/discuss.php?d=1822]

=== Per-discussion subscription in Forums ===

The facility for per-discussion subscription in Forums is a Feature Request in the Moodle Tracker dating back to 2004(!), with 149 votes, and almost 100 people watching or participating. [https://tracker.moodle.org/browse/MDL-1626]

This might not be sexy enough for a Summer of Code project, or perhaps even too difficult to implement within the time available?

:'''Skills required''': PHP
:'''Difficulty level''': Medium-Advanced
:'''Possible mentor''':
:'''Discussion''': [https://moodle.org/mod/forum/discuss.php?d=243959]

==See also==

* [[GSOC]] - describing Moodle's involvement with Google in their Summer of Code program
* [http://tracker.moodle.org/secure/IssueNavigator!executeAdvanced.jspa?jqlQuery=type+in+%28%22New+Feature%22%2C+Improvement%29+AND+resolution+%3D+unresolved+ORDER+BY+votes+DESC&runQuery=true&clear=true Popular new feature and improvement requests in Tracker]

[[Category:GSOC]]

User talk:Stuart Mealor

2009-09-10T21:07:56Z

Stuartrmealor: New page: This is my talk page eh?

This is my talk page eh?

User:Stuart Mealor

2009-08-27T05:23:32Z

Stuartrmealor:

Hi :-)
* I'm Managing Director of ''[http://www.hrdnz.com HRDNZ]'', Moodle Partner in New Zealand.
We run the ''[http://www.moodlemoot.co.nz Moodle Moot]'' in NZ each year
* I'm Moodle Certification Manager - which is currently the Moodle Course Creator Certificate (MCCC) ''[http://moodle.org/course/view.php?id=48 Moodle Certification]''.
* I'm also joint facilitator of the ''[http://moodle.org/course/view.php?id=32 Moodle Business Uses]'' area (Also run the ''[http://www.linkedin.com/groups?gid=128299 Linkedin MoodleUsers Group]''
* I've presented at Moodle Moots meeting fantastic people along the way(!) in:
** Australia (Sydney and Brisbane)
** Muscat (Oman)
** Rome (Italy)
** Barcelona (Spain)
** San Francisco twice and Oklahoma (USA)
** 5(!) Moots in New Zealand.
** Also you might have met me at LearnX, E-Fest, ULearn, or Ascilite conferences.

Please say hello on my [[User talk:Stuart Mealor|talk page]] :-)

User:Stuart Mealor

2009-08-27T05:19:37Z

Stuartrmealor:

Hi :-)
* I'm Managing Director of ''[http://www.hrdnz.com HRDNZ]'', Moodle Partner in New Zealand.
We run the ''[http://www.moodlemoot.co.nz Moodle Moot]'' in NZ each year
* I'm Moodle Certification Manager - which is currently the Moodle Course Creator Certificate (MCCC) ''[http://moodle.org/course/view.php?id=48 Moodle Certification]''.
* I'm also joint facilitator of the ''[http://moodle.org/course/view.php?id=32 Moodle Business Uses]'' area
* I've presented at Moodle Moots meeting fantastic people along the way(!) in:
** Australia (Sydney and Brisbane)
** Muscat (Oman)
** Rome (Italy)
** Barcelona (Spain)
** San Francisco twice and Oklahoma (USA)
** 5(!) Moots in New Zealand.
** Also you might have met me at LearnX, E-Fest, ULearn, or Ascilite conferences.

Please say hello on my [[User talk:Stuart Mealor|talk page]] :-)

User:Stuart Mealor

2009-08-27T05:09:18Z

Stuartrmealor:

Hi :-)
* I'm Managing Director of HRDNZ, Moodle Partner in New Zealand.
We run the ''[http://www.moodlemoot.co.nz Moodle Moot]'' in NZ each year
* I'm Moodle Certification Manager - which is currently the Moodle Course Creator Certificate (MCCC) ''[http://moodle.org/course/view.php?id=48 Moodle Certification]''.
* I'm also joint facilitator of the ''[http://moodle.org/course/view.php?id=32 Moodle Business Uses]'' area
* I've presented at Moodle Moots in:
** Australia (Sydney and Brisbane)
** Muscat (Oman)
** Rome (Italy)
** Barcelona (Spain)
** San Francisco x2 and Oklahoma (USA)
** 5(!) Moots in New Zealand.
** Also you might have met me at LearnX, E-Fest, ULearn, or Ascilite conferences.

Please say hello on my [[User talk:Stuart Mealor|talk page]] :-)

User:Stuart Mealor

2009-08-27T05:07:41Z

Stuartrmealor:

Hi :-)
* I'm Managing Director of HRDNZ, Moodle Partner in New Zealand.
We run the ''[http://www.moodlemoot.co.nz Moodle Moot]'' in NZ each year
* I'm Moodle Certification Manager - which is currently the Moodle Course Creator Certificate (MCCC) ''[http://moodle.org/course/view.php?id=48 Moodle Certification]''.
* I'm also joint facilitator of the Moodle Business Uses area ''[http://moodle.org/course/view.php?id=32 Moodle Business Uses]''
* I've presented at Moodle Moots in
** Australia (Sydney and Brisbane)
** Muscat (Oman)
** Rome (Italy)
** Barcelona (Spain)
** San Francisco x2 and Oklahoma (USA)
** 5 Moots in New Zealand.
** Also you might have met me at LearnX, E-Fest, ULearn, or Ascilite conferences.

Please say hello on my [[User talk:Stuart Mealor|talk page]] :-)

User:Stuart Mealor

2009-08-27T04:55:30Z

Stuartrmealor: New page: Hi :-) * I'm Managing Director of HRDNZ, Moodle Partner in New Zealand. We run the ''[http://moodle.org/course/view.php?id=32 Moodle Moot]'' in NZ each year * I'm Moodle Certification Man...

Hi :-)
* I'm Managing Director of HRDNZ, Moodle Partner in New Zealand.
We run the ''[http://moodle.org/course/view.php?id=32 Moodle Moot]'' in NZ each year
* I'm Moodle Certification Manager - which is currently the Moodle Course Creator Certificate (MCCC) ''[http://moodle.org/course/view.php?id=48 Moodle Certification]''.
* I'm also joint facilitator of the Moodle Business Uses area ''[http://moodle.org/course/view.php?id=32 Moodle Business Uses]''
* I've presented at Moodle Moots in Australia (Sydney and Brisbane), Muscat (Oman), Rome (Italy), Barcelona (Spain), San Francisco x2 and Oklahoma (USA), as well as 5 Moots in New Zealand. Also you might have met me at LearnX, E-Fest, ULearn, or Ascilite conferences.

Please say hello on my [[User talk:Stuart Mealor|talk page]] :-)