MoodleDocs - User contributions [en]

Cron with Unix or Linux

2024-12-15T13:14:49Z

Mits: ja link

{{Installing Moodle}}
On Unix and Linux use the built in ''cron'' program which is standard on nearly all systems. You are required to add a command to the 'crontab' (the table that holds cron commands) for the web server user.

There are two different methods that can be used to invoke the Moodle cron process:

'''NOTE:''' The commands shown need to be added to the crontab to function (described in a moment). However, you can - and should - run them on the command line to check they work first.

== Method 1: The command line (cli) cron ==

If you have a choice, this is normally the best way to run Moodle cron.

PHP is also capable of running programs directly from the command line. Your system needs to be set up to do this; specifically you need the 'CLI' version of PHP to be installed. Most systems with PHP installed will have this by default. If you have the PHP CLI version installed then this is the recommended method of invoking cron. The correct command will be something like...
<pre>
/usr/bin/php /path/to/moodle/admin/cli/cron.php
</pre>
(substitute the correct path to moodle and for php as required)

You can simply type this on the command line this to see if it works. If you are not sure about the path to PHP you can type "<code>which php</code>".

'''Tip:''': If you have problems, see the [[PHP]] page. In particular, suspect an alternate php.ini for the CLI PHP command which may not have suitable settings.

== Method 2: Web based cron ==

'''NOTE:''' In order to use the web based cron script you must first check [[Cron settings]] to make sure this method is permitted.

The idea is to call the following web page (you can try this from your browser):
<pre>
http://url.of.your/moodle/admin/cron.php
</pre>

A command line (text based) browser is needed to run this on the server. Possibilities are as follows (OSX, for example, only ships with curl)...
<pre>
/usr/bin/wget -q -O /dev/null/ http://url.of.your/moodle/admin/cron.php
</pre>
(no output is displayed - remove the ''-O /dev/null/'' to test)

...OR...

<pre>
/usr/bin/curl http://url.of.your/moodle/admin/cron.php -o /dev/null/ -silent
</pre>
(no output is displayed - remove the ''-o /dev/null/ -silent'' to test)

==Using the crontab program on Unix/Linux==

Once you have selected (and tested!) an appropriate command to invoke the Moodle cron it must be added to the web users 'crontab' to schedule it to run regularly. 'Crontab' is both a file containing the user's cron commands and is also the name of the (command line) program used to edit it. Use the following command (as root) substituting the correct user in place of 'www-data' (e.g. 'apache' for CentOS, 'www-data' for Debian/Ubuntu, '_www' for macOS—Google will know!)
<pre>
# crontab -u www-data -e
</pre>
This will bring up an editor window (the first time it may ask you which editor to use). Add the command onto the end of the file in this way (it may be empty or it may have some instructional comments):
<pre>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php
</pre>
The first five * entries specify the times, followed by the command, to run. This says to run the command as often as possible, i.e. every minute.

See https://en.wikipedia.org/wiki/Cron#CRON_expression for details on cron expressions.

== See also ==

* [http://linuxweblog.com/node/24 A basic crontab tutorial]
* [http://www.freebsd.org/cgi/man.cgi?query=crontab&apropos=0&sektion=5&manpath=FreeBSD+6.0-RELEASE+and+Ports&format=html Online version of the man page]

[[es:Cron con Unix o Linux]]
[[ja:UnixまたはLinuxでのCron]]

Backpacks

2024-01-14T15:04:25Z

Mits: ja link

{{Badges}}
Enabling users to connect to an external backpack means they can add badges from their Moodle site to their backpack and also display badges from other sites in their Moodle profile.

'''! NOTE: There is a currently known problem with displaying badges from other sites - see https://tracker.moodle.org/browse/MDL-79302'''
[[File:ManageBackPacks.png|thumb|Manage backpacks]]
==Site administration settings==
The backpack badgr.io is provided by default. Admins can add additional backpacks, for users with an account on eu.badgr.io, ca.badgr.io or au.badgr.io.

For example, to add the eu.badgr.io follow the steps:
# Go to Site administration / Badges / Manage backpacks.
# Click the button 'Add a new backpack'.
# Create this backpack with the following details:
#* Backpack API URL - https://api.eu.badgr.io/v2
#* Backpack URL - https://eu.badgr.io
#* API version - Open Badges v2.0
#* (Leave 'Include authentication details with the backpack' unticked.)
Follow the same process for ca.badgr.io and au.badgr.io changing only the region letters (the ''eu'' in the above URLs to ''ca'' or ''au'').

Note the admin can set the order in which backpacks are listed for users.
==Individual user settings==
You can connect to your backpack as follows:
# In the user menu (top right), select Preferences, then 'Backpack settings' under Badges.
# If necessary, select your backpack provider.
# Enter your Badgr user account email and password.
# Look in your mailbox for a verification email and copy and paste the link to verify your connection to the backpack.
After the backpack connection is successfully established, badges from your backpack can be displayed on your badges page and your profile page. Go to Manage badges (via Preferences / Badges) and click the icon to add your badge to your backpack.

You can also select collections of badges from your backpack that you would like to display in your profile.
==Open Badges v 2.1==
Moodle is Open Badges v 2.1 compliant and a new [[OAuth 2 Open Badges service]] enables users to connect to their OB v 2.1 compliant backpack without having to enter their credentials into Moodle.

To connect to an OB v 2.1 compliant backpack such as badgr.com
# Go to Site administration / Badges / Manage backpacks.
# Click the button 'Add a new backpack'.
# Create this backpack with the following details:
#* API version - Open Badges v2.1
#* Backpack URL - https://badgr.com
When you connect to an OB v 2.1 compliant backpack, a Badges service in [[OAuth 2 services]] is created automatically.
[[https://docs.moodle.org/es/Mochilas]]
[[https://docs.moodle.org/de/Backpacks]]

[[es:Mochilas]]
[[ja:バックパック]]

Backpacks

2024-01-14T15:03:51Z

Mits: ja link

OAuth 2 Troubleshooting

2023-12-22T13:44:17Z

Mits: ja link

==Troubleshooting==
===On the 'OAuth 2 services' page, there is a red cross for 'Allow login'===
To get a green tick for Allow login, edit the OAuth 2 service and make sure that the setting 'Show on login page' is ticked.
===I obtain a coding error after enabling OAuth 2 authentication===
Have you any OAuth 2 plugins for earlier versions installed on your site? If so, you will need to [[Installing plugins|uninstall them]] in order to use the standard OAuth 2 authentication.
===I obtain an error message when attempting to log in using Facebook===
The error message 'The user information returned did not contain a username and email address. The OAuth 2 service may be configured incorrectly.' is most likely because the user's Facebook account was created using a mobile number.

The solution is for the user to first log in to Facebook and add a username and email address there.
===I see a "required paramenter (code) was missing" error after logging into the OAuth 2 service===
The error message 'A required parameter (code) was missing' can be caused by a mis-configured webserver. OAuth 2 relies on long tokens passed as url parameters, and some webserver configurations will prevent this from working. See http://www.php.net/manual/en/reserved.variables.get.php#101469 for one possible solution.
===I have all green checkmarks on my /admin/tool/oauth2/issuers.php page for Google & Facebook but no buttons show on my servers login page===
It was discovered that in a fresh install of Moodle 3.4 (probably for security reasons) that the plugin configuration for OAuth2 was in a disabled state. Go to your page for Site Administration - Plugins - Authentication - Manage authentication (/admin/settings.php?section=manageauths), and enable the record for OAuth2, then optionally tweak your settings for that record.

[[ja:OAuth 2トラブルシューティング]]

OAuth 2 authentication

2023-12-03T09:31:48Z

Mits: ja link

{{Authentication}}
== Overview ==
OAuth 2.0 is the de facto industry standard protocol for user authorisation. OAuth 2 authentication enables users to access Moodle via buttons on the login page using their credentials from popular service providers, such as Google, Microsoft, Facebook, and LinkedIn.
[[File:OAuth Login.png|border|center|frameless|600x600px]]
The following high-level interaction process illustrates how OAuth 2 authentication works in a Moodle context:
[[File:OAuth - Service Provider Authentication.png|border|center|frameless|600x600px]]

An OAuth service provider is an external system (“in the cloud”) that provides identity (via the authorisation server) and API access (via the resource server) by issuing OAuth access tokens to a client (Moodle). Let’s go through the interactions from top to bottom:
# A user sends an authorisation request; that is, a user logs in to the service provider via the client. This step is initiated via the service provider buttons on the Moodle login screen.
# The authorisation server issues an authorisation code if the entered credentials are valid. Once this has taken place, the user is authenticated with Moodle. If account creation is enabled (the Prevent account creation when authenticating setting), a new account will be created. Otherwise, the user will be prompted to link the authorisation to an existing account with the same email address. An entry can be found in the [[Linked logins]] section in the user’s preferences.
# An access token will be issued when the user logs in using the stored authorisation code. A scheduled task exists to regularly update the OAuth 2 tokens (\core\oauth2\refresh_ system_tokens_task).
# Moodle uses this access token for any internal services that require a resource from the service provider, for instance, a link to files in a repository. Some internal services require a system account to be connected.
==Setting up OAuth 2 authentication==
To use OAuth 2 authentication, an administrator must follow the following steps:
# Configure OAuth 2 services: Go to '''Site administration > Server > OAuth 2 services''', and following the instructions on the [[OAuth 2 services]] page.
# Enable OAuth 2: Go to '''Site administration > Plugins > Authentication''', enable '''OAuth 2'''.
# Configure OAuth 2 lock user fields: To control if and how certain user data fields are being populated, click on the '''Settings''' link and configure your '''Lock user fields'''.
# Prevent account creation: By default, account creation is enabled. If you wish to prevent account creation, go to '''Site administration > Plugins > Authentication''' and enable the setting "authpreventaccountcreation".
# Testing, testing, testing: To verify that your OAuth 2 configuration is working, go to '''Site administration > Plugins > Authentication''' and click on the '''Test settings''' link in the '''OAuth 2''' row. Here, you can select a service and test its connection.
OAuth 2 authentication is supported by the following Moodle features:
* Repositories: [[Dropbox repository]], [[Google Drive repository]], Microsoft [[OneDrive repository]], and [[Nextcloud repository]]
* Portfolios: [[Google Drive portfolio]]
* Badges: [[Backpacks|Open Badges 2.1]]
* Mail: Incoming and outgoing [[Mail configuration|mail configuration]]
* Document converters: [[Google Drive converter]]
==See also==
* [[OAuth 2 Troubleshooting|OAuth 2 troubleshooting]]
[[Category:OAuth 2]]
[[es:Autenticación OAuth 2]]
[[de:OAuth2 Authentifizierung]]
[[ja: OAuth 2認証]]

OAuth 2 Open Badges service

2023-01-16T10:43:01Z

Mits: ja link

{{OAuth2}}

You need to set up an OAuth 2 Open Badges service in order to enable users to connect to their Open Badges v 2.1 compliant backpack without having to enter their credentials into Moodle.

''Please add instructions here...''

==See also==

* The section 'Open Badge Connect API' in the dev doc [[:dev:OAuth 2 API|OAuth 2 API]]

[[Category: Badges]]

[[es:Servicio OAuth2 Open Badges]]
[[de:OAuth2 Open Badges Service]]
[[ja:OAuth 2 Open Badgesサービス]]

Portfolio Plugin for Evernote

2023-01-11T15:04:34Z

Mits: ja link

{{Portfolios}}
== Introduction ==
Evernote is used by a large number of people to store their daily files and activities. Especially, in the field of education, many educators and students use Evernote to share their notes with others. With this plugin, the users are able to sync their Moodle and Evernote activities in a better way. This plugin enables the users to export the desired Moodle content to their Evernote accounts in a clean and simple way.

== Installation Steps ==
* If you don't have an Evernote API key beforehand, go through the following steps:
** Go to [http://dev.evernote.com/doc/ Evernote Developer's page].
** Click on 'Get an API Key button'
** In the API Permissions block, click on 'Full Access'. Then fill up the other details and submit the form.
** Register your API key as a public key from Evernote.
* Now having the Evernote key, you need to request Evernote for activating the key. This will ensure that the key works on the Evernote production servers (The key which is not activated, runs only for [https://sandbox.evernote.com Evernote Sandbox Accounts]). If you don't have an activated key yet, follow the following steps:
** Go to [http://dev.evernote.com/support/ Evernote Support].
** Click on the button 'Activate an API Key
** Fill in the correct details and submit the form.
** Please note that it might take a few days for Evernote to activate the API Key.
* Download the Evernote Portfolio plugin from [https://github.com/thatsvishalhere/moodle-portfolio_evernote/archive/master.zip Github].
* Extract the zip file in your Moodle directory (Moodle_folder)/portfolio.
* Rename the folder of the plugin to 'evernote'.
* Log in to Moodle as administrator and install the Evernote Portfolio.
* Ensure that Portfolios are enabled on the site on Site Administration->Advanced Features.
* Enable the Evernote plugin from Site Administration->Plugins->Portfolios->Manage Portfolios
* In the form that appears, select 'No' for Using Testing Server if the Evernote Key has been activated. Else, select 'Yes'. Note that while using testing server, you'll be using the Evernote Key for the [https://sandbox.evernote.com Evernote Sandbox Accounts]. This is a testing platform provided by Evernote to test out the plugin before use. You'll need to have a separate Sandbox account to test the plugin on your account. The Sandbox account is independent of the main Evernote account.
* Enter the API Key and the Secret Key you registered at Evernote and click on Save.
* You have now activated the plugin for Evernote.

== Moodle Versions Supported ==
Currently the plugin supports Moodle versions from 2.3 and upwards.

== Items which may be exported to portfolio ==
Export of all the items which are supported by default in Moodle Portfolio are supported. They are listed below:
* Assignment submissions - single and multiple file uploads
* Chat sessions
* Database activity module entries
* Database activities
* Forum posts
* Glossary entries

== Sending the Data to your Evernote Accounts ==
* Click on Export to Portfolio link on any forum post/chat sessions/database entries and activities/assignment/glossary entries you want to send to your Evernote Account.
* Select 'Evernote' and click 'Next'.
* Fill out the necessary details and click 'Next'.
* Here you get the summary of the details you had entered in the previous form. Click 'Next' to finalize the export.

[[ja:Evernote用ポートフォリオプラグイン]]

Capabilities/moodle/course:configuredownloadcontent

2022-12-13T15:01:30Z

Mits:

{{Capabilities}}

*This allows a user to configure the [[Download course content]] feature.
*This capability is allowed for the default roles of manager and teacher.

[[Category:Capabilities]]

[[es:Capabilities/moodle/course:configuredownloadcontent]]
[[de:Capabilities/moodle/course:configuredownloadcontent]]
[[ja:ケイパビリティ/moodle/course:configuredownloadcontent]]

Capabilities/webservice/amf:use

2020-04-29T15:02:14Z

Mits:

{{Capabilities}}
*This allows a user to use the AMF protocol for [[Web services]].
*This capability is not set for any of the default roles.

[[Category:Capabilities|Webservice]]
[[Category:Web Services]]

[[eu:Capabilities/webservice/amf:use]]
[[es:Capabilities/webservice/amf:use]]
[[de:Capabilities/webservice/amf:use]]
[[ja:ケイパビリティ/webservice/amf:use]]

Capabilities/webservice/amf:use

2020-04-29T15:01:56Z

Mits: ja link

Capabilities/webservice/soap:use

2020-04-27T14:01:44Z

Mits:

{{Capabilities}}
*This allows a user to use the SOAP protocol for [[Web Services]].
*This capability is not set for any of the default roles.

[[Category:Capabilities|Webservice]]
[[Category:Web Services]]

[[eu:Capabilities/webservice/soap:use]]
[[es:Capabilities/webservice/soap:use]]
[[de:Capabilities/webservice/soap:use]]
[[ja:ケイパビリティ/webservice/soap:use]]

Capabilities/webservice/soap:use

2020-04-27T14:01:25Z

Mits: ja link

Using web services

2020-04-25T13:49:38Z

Mits: ja link

{{Web services}}
This document explains how an administrator can set up a web service for users to access a service. Each user will have a specific and unique security key (also known as a "token") to access the service.

== Enabling web services==
[[Image:Enable_web_service.jpg|thumb|Enabling web services]]
# Access ''Administration > Site administration > Advanced features''
# Check 'Enable web services' then click 'Save Changes'

Note: For security reasons, web services should only be enabled if you intend to make use of it.

== Enabling protocols ==
[[Image:Enable_protocol.jpg|thumb|left|Enabling protocols]]
Usually external applications that users wish to use dictate which protocols should be enabled.

# Access ''Administration > Site administration > Plugins > Web services > Manage protocols''
# Enable the protocols (SOAP, REST, XMLRPC, AMF, ...) as required

== Enabling web service function documentation ==
[[Image:Security keys and documentation.jpg|thumb|Security keys page with documentation link]]
Enabling web service function documentation (also on the Manage protocols page) results in user-specific web service documentation being available for each user on their [[Security keys]] page. This option is mainly useful to web service client developers. If nobody is creating a web service client, there is no need to enable this feature.

== Creating a service ==
If none of the pre-build web services match your needs, you can create a custom service i.e. select which of the standard web service functions are available via that service.

You can enable only the specific functions that you need to expose, so not compromising on security.
[[Image:Create a service.jpg|thumb|Creating a service|left]]
# Access ''Administration > Site administration > Plugins > Web services > External services''
# Click Add new custom service
#* 'Authorised users only' - If enabled, you will need to select the authorised users manually. Otherwise all users with appropriate permissions are allowed
#* 'Required capability' - If enabled, any user accessing the web service will be checked against this selected capability. (This is just an additional optional security layer.)
# Enter a name and check Enabled
# Click the button 'Add service'

==Adding functions to the service==
[[Image:Select a web service function.jpg|thumb|Adding functions to the service]]Your service is currently empty and doesn't do anything. Web service functions need to be added. Your choice will be dictated by what you allow the external application to do. For this example, select 'Create group'.

# Click 'Add functions' link
# Select 'create group' function and click the 'Add functions' button

''Note that deprecated functions can not be added to services although the ones that are already part of a service can remain there until they are removed from Moodle codebase.''

You should be back to the service functions list. 'Required capabilities' are indicated for each function. Users need the required capabilities to run a function. The function descriptions in the API Documentation can also give you more information about the required capabilities (''Administration > Site administration > Plugins > Web services > API Documentation'').

==Enabling capabilities==

The final step is to grant appropriate permissions. The following capabilities should be allowed:

* [[Capabilities/moodle/webservice:createtoken|moodle/webservice:createtoken]] - for allowing users to generate a security key
* [[Capabilities/webservice/rest:use | webservice/rest:use]], [[Capabilities/webservice/soap:use | webservice/soap:use]], [[Capabilities/webservice/xmlrpc:use | webservice/xmlrpc:use]], [[Capabilities/webservice/amf:use | webservice/amf:use]] which match the enabled protocols.
* The service ''Required capability'' if set (''Administration > Site administration > Plugins > Web services > Manage services >'''Edit''' link'').
* The required capabilities for the web service functions. These required capabilities are listed when you add a function to the service. For more information about roles and capabilities, read the [[Manage roles]] documentation.

Once done, the web service should be set up. Users should be able to [[Security keys|obtain a personal security key]].

= Alternative settings =

== Authorise only specific users==
[[Image:Authorised users link.jpg|thumb]] [[Image:Authorised user selection page.jpg|thumb]]
# ''Administration > Site Administration > Plugins > Web services > External Services''
# Select '''Authorised users''' link (the service must have been set as '''Authorised users only''' in the '''Edit''' link)
# Select some users and click '''Add'''

Moodle indicates if some capabilities need to be assigned to an authorised user. Moreover if you click on the authorised user fullname, you can set up some specific options: ''IP restriction'' and ''Valid until''.

== Create a token ==
[[Image:Create_token.jpg|thumb]]
This feature allows you to create a token for specific user. It can be useful if a user doesn't have the moodle/create:token capability. This is also the only way to create a token for an administrator. For security reason, tokens are not automatically generated in the administrator security keys page.

# ''Administration > Site Administration > Plugins > Web services > Manage tokens''
# Click on '''Add'''
# Select the created user and service
# Click on '''Saves changes'''

As you created a token for this user, you do not need to assign "''moodle/webservice:createtoken''" to him/her.
Finally, note that, as for authorised users, you can also set ''IP restriction'' and ''Valid until'' on a token.

== See also ==

*[http://www.joomdle.com/wiki/Preparing_Moodle_20#Setting_up_Moodle_Web_services Joomdle documentation about setting Moodle web services]

[[de:Webservices nutzen]]
[[fr:Utilisation des services Web]]
[[ja:ウェブサービスを使用する]]

Caching

2020-04-11T15:07:18Z

Mits: ja link

{{Performance}}
A cache is a collection of processed data that is kept on hand and re-used in order to avoid costly repeated database queries.

Moodle 2.4 saw the implementation of MUC, the Moodle Universal Cache. This new system allows certain functions of Moodle (eg string fetching) take advantage of different installed cache services (eg files, ram, memcached).

In future versions of Moodle we will continue expanding the number of Moodle functions that use MUC, which will continue improving performance, but you can already start using it to improve your site.

==General approach to performance testing==

Here is the general strategy you should be taking:

# Build a test environment that is as close to your real production instance as possible (eg hardware, software, networking, etc)
# Make sure to remove as many uncontrolled variables as you can from this environment (eg other services)
# Use a tool to place a realistic, but simulated and repeatable load upon you server. (eg jmeter or selenium).
# Decide on a way to measure performance of the server by capturing data (ram, load, time taken, etc)
# Run your load and measure a baseline performance result.
# Change one variable at a time, and re-run the load to see if performance gets better or worse. Repeat as necessary.
# When you discover settings that result in a consistent performance improvement, apply to your production site.

==Cache configuration in Moodle==

Since Moodle 2.4, Moodle has provided a caching plugin framework to give administrators the ability to control where Moodle stores cached data. For most Moodle sites the default configuration should be sufficient and it is not necessary to change the configuration. For larger Moodle sites with multiple servers, administrators may wish to use memcached, mongodb or other systems to store cache data. The cache plugin screen provides administrators with the ability to configure what cache data is stored where. 
Caching in Moodle is controlled by what is known as the Moodle Universal Cache. Commonly referred to as MUC.

This document explains briefly what MUC is before proceeding into detail about the concepts and configuration options it offers.

==The basic cache concepts in Moodle==
Caching in Moodle isn't as complex as it first appears. A little background knowledge will go a long way in understanding how cache configuration works.

===Cache types===
Let's start with cache types (sometimes referred to as mode). There are three basic types of caches in Moodle.

The first is the application cache. This is by far the most commonly used cache type in code. Its information is shared by all users and its data persists between requests. Information stored here is usually cached for one of two reasons, either it is required information for the majority of requests and saves us a one of more database interactions or it is information that is accessed less frequently but is resource intensive to generate. 
By default this information is stored in an organised structure within your Moodle data directory.

The second cache type is the session cache. This is just like the PHP session that you will already be familiar with, in fact it uses the PHP session by default. You may be wondering why we have this cache type at all, but the answer is simple. MUC provides a managed means of storing, and removing information that is required between requests. It offers developers a framework to use rather than having to re-invent the wheel and ensures that we have access to a controlled means of managing the cache as required. 
Its important to note that this isn't a frequently used cache type as by default session cache data is stored in the PHP session and the PHP session is stored in the database. Uses of the session cache type are limited to small datasets as we don't want to bloat sessions and thus put strain on the database.

The third and final type is the request cache. Data stored in this cache type only persists for the lifetime of the request. If you're a PHP developer think of it like a managed static variable. 
This is by far the least used of the three cache types, uses are often limited to information that will be accessed several times within the same request, usually by more than an area of code.
Cached information is stored in memory by default.

==== Cache types and multiple-server systems ====

If you have a system with multiple front-end web servers, the application cache must be shared between the servers. In other words, you cannot use fast local storage for the application cache, but must use shared storage or some other form of shared cache such as a shared memcached.

The same applies to session cache, unless you use a 'sticky sessions' mechanism to ensure that within a session, users always access the same front-end server.

===Cache backends===
Cache backends are where data actually gets stored. These include things like the file system, php session, Memcached, and memory. 
By default just file system, php session, and memory are used within Moodle. 
We don't require that a site has access to any other systems such a Memcached. Instead that is something you are responsible for installing and configuring yourself. 
When cache backends are mentioned think of systems outside of Moodle that can be used to store data. The MongoDB server, the Memcached server and similiar "server" applications.

===Cache stores===

Cache stores are a plugin type within Moodle. They facilitate connecting Moodle to the cache backends discussed above. The standard Moodle has the three defaults mentioned above as well as Memcached, MongoDB, [[APC user cache (APCu)|APC user cache (APCu)]] and [[Redis cache store|Redis]].

You can find other cache store plugins in the [https://moodle.org/plugins/browse.php?list=category&id=48 plugins database].

The code for these is located within cache/stores in your Moodle directory root.

Within Moodle you can configure as many cache stores as your architecture requires. If you have several Memcached servers, for instance, you can create a cache store instance for each. Moodle by default contains three cache store instances that get used when you've made no other configuration.
* A file store instance is created which gets used for all application caches. It stores its data in your moodledata directory.
* A session store instance is created which gets used for all session caches. It stores its data in the PHP session, which by default is stored in your database.
* A static memory store instance is created which gets used for all request cache types. Data exists in memory for just the lifetime of a request.

===Caches: what happens in code===
Caches are created in code and are used by the developer to store data they see a need to cache. 
Let's keep this section nice and short because perhaps you are not a developer. There is one very important point you must know about. 
The developer does not get any say in where the data gets cached. They must specify the following information when creating a cache to use.
# The type of cache they require.
# The area of code this cache will belong to (the API if you will).
# The name of the cache, something they make up to describe in one word what the cache stores.

There are several optional requirements and settings they can specify as well, but don't worry about that at this point. 
The important point is that they can't choose which cache backend to use, they can only choose the type of cache they want from the three detailed above.

===How it ties together===

This is best described in relation to roles played in an organisation.

# The system administrator installs the cache backends you wish to use. Memcached, XCache, APC and so on. Moodle doesn't know about these, they are outside of Moodle's scope and purely the responsibility of your system administrator.
# The Moodle administrator creates a cache store instance in Moodle for each backend the site will make use of. There can be one or more cache stores instances for each backend. Some backends like Memcached have settings to create separated spaces within one backend.
# The developer has created caches in code and is using them to store data. He doesn't know anything about how you will use your caches, he just creates a "cache" and tells Moodle what type it is best for it.
# The Moodle administrator creates a mapping between a cache store instance and a cache. That mapping tells Moodle to use the backend you specify to store the data the developer wants cached.

In addition to that, you can take things further still.
* You can map many caches to a single cache store instance.
* You can map multiple cache store instances to a single cache with priority (primary ... final)
* You can map a cache store instance to be the default store used for all caches of a specific type that don't otherwise have specific mappings.

If this is the first time you are reading about the Moodle Universal Cache this probably sounds pretty complex but don't worry it will be discussed in better detail as we work through how to configure the caching in Moodle.

==Advanced concepts==
These concepts are things that most sites will not need to know or concern themselves about.

You should only start looking here if you are looking to maximise performance on large sites running over clustered services with shared cache backends, or on multi-site architecture again where information is being shared between sites.

===Locking===

The idea of locking is nothing new, it is the process of controlling access in order to avoid concurrency issues.

MUC has a second type of plugin, a cache lock plugin that gets used when caches require it. To date no caches have required it. A cache by nature is volatile and any information that is absolutely mission critical should be a more permanent data store likely the database.

Nonetheless there is a locking system that cache definitions can require within their options and that will be applied when interacting with a cache store instance.

===Sharing===

Every bit of data that gets stored within a cache has a calculated unique key associated with it. 
By default part of that key is the site identifier making any content stored in the cache specific to the site that stored it. For most sites this is exactly what you want. 
However, in some situations, it's beneficial to allow multiple sites, or somehow linked sites to share cached data. 
Of course, not all caches can be shared, however some certainly can and by sharing you can further reduce load and increase performance by maximising resource use.

This is an advanced feature, if you choose to configure sharing please do so carefully.

To make use of sharing you need to first configure identical cache store instances in the sites you want to share information, and then on each site set the sharing for the cache to the same value.

; Sites with the same site ID: This is the default, it allows for sites with the same site ID to share cached information. It is the most restrictive but is going to work for all caches. All other options carry an element of risk in that you have to ensure the information in the cache is applicable to all sites that will be accessing it.
; Sites running the same version: All sites accessing the backend that have the same Moodle version can share the information this cache has stored in the cache store.
; Custom key: For this, you manually enter a key to use for sharing. You must then enter the exact same key into the other sites you want to share information.
; Everyone: The cached data is accessible to all other sites accessing the data. This option puts the ball entirely in the Moodle administrators court.

As an example if you had several Moodle sites all the same version running on a server with APC installed you could decide to map the language cache to the APC store and configure sharing for all sites running the same version. 
The language cache for sites on the same version is safe to share in many situations, it is used on practically every page, and APC is extremely fast. These three points may result in a nice wee performance boost for your sites. 
It is important to consider with the language cache that by sharing it between sites any language customisations will also be shared.

==The cache configuration screen==

The cache configuration screen is your one stop shop for configuring caching in Moodle. 
It gives you an overview of how caching is currently configured for your site and it provides links to all of the actions you can perform to configure caching to your specific needs.

===Accessing the cache configuration screen===

[[Image:cacheadmin29.png|thumb|500px|The cache configuration screen]]

The cache configuration screen can only be accessed by users with the ''moodle/site:config'' capability. By default this is only admins. 
Once logged in the configuration screen can be found in '''Site Administration > Plugins > Caching > Configuration'''.

===Installed cache stores===

[[Image:ist29.png|thumb|500px|Installed cache stores screenshot]]

This is showing you a list of cache store plugins that you have installed. 
For each plugin you can quickly see whether it is ready to be used (any PHP requirements have been met), how many store instances already exist on this site, the cache types that this store can be used for, what features it supports (advanced) and any actions you can perform relating to this store.

Often the only action available is to create a new store instance. 
Most stores support having multiple instances, however not all as you will see that that the session cache and static request cache do not. For those two stores, it does not make sense to have multiple instances.

===Configured store instances===

[[Image:csi29.png|thumb|500px|Configured store instances screenshot]]

Here you get a list of the cache store instances on this site.

; '''Store name''': The name given to this cache store instance when it is created so that you can recognise it. It can be anything you want and is only used so that you can identify the store instance.
; '''Plugin''': The cache store plugin of which this is an instance of.
; '''Ready ''': A tick gets shown when all PHP requirements have been met as well as any connection or set-up requirements have been verified.
; '''Store mappings''': The number of caches this store instance has been mapped to explicitly. Does not include any uses through default mappings (discussed below).
; '''Modes''': The modes that this cache store instance can serve.
; '''Supports''': The features supported by this cache store instance.
; '''Locking ''': Locking is a mechanism that restricts access to cached data to one process at a time to prevent the data from being overwritten. The locking method determines how the lock is acquired and checked.
; '''Actions''': Any actions that can be performed against this cache store instance.

===Known cache definitions===

[[Image:caching-27-04-known-cache-definitions.png|thumb|500px|Known cache definitions screenshot]]

The idea of a cache definition hasn't been discussed here yet. It is something controlled by the developer. When they create a cache they can do so in two ways, the first is by creating a cache definition. This is essentially telling Moodle about the cache they've created. The second way is to create an Adhoc cache. Developers are always encouraged to use the first method. Only caches with a definition can be mapped and further configured by the admin. Adhoc caches will make use of default settings only. 
Typically Adhoc caches are only permitted in situations where the cache is small and configuring it beyond defaults would provide no benefit to administrators. Really it's like saying you the administrator doesn't need to concern yourself with it.

For each cache shown here you get the following information:

; '''Definition''' : A concise description of this cache.
; '''Mode''': The cache type this cache is designed for.
; '''Component ''': The code component the cache is associated with.
; '''Area''': The area of code this cache is serving within the component.
; '''Store mappings''': The store or stores that will be used for this cache.
; '''Sharing''': How is sharing configured for this site.
; '''Actions''': Any actions that can be performed on the cache. Typically you can edit the cache store instance mappings, edit sharing, and purge the cache.

You'll also find at the bottom of this table a link title "Rescan definitions". Clicking this link will cause Moodle to go off an check all core components, and installed plugins looking for changes in the cache definitions. 
This happens by default during an upgrade, and if a new cache definition is encountered. However, should you find yourself looking for a cache that isn't there this may be worth a try. 
It is also handy for developers as it allows them to quickly apply changes when working with caches. It is useful when tweaking cache definitions to find what works best.

Information on specific cache definitions can be found on the [[Cache definitions]] page.

===Summary of cache lock instances===

[[Image:caching-27-05-summary-of-cache-lock-instances.png|thumb|500px|Summary of cache lock instances screenshot]]

As mentioned above cache locking is an advanced concept in MUC. 
The table here shows information on the configured locking mechanisms available to MUC. By default, just a single locking mechanism is available, file locking.
At present, there are no caches that make use of this and as such I won't discuss it further here.

===Stores used when no mapping is present===

[[Image:caching-27-06-stores-used-when-no-mapping-is-present.png|thumb|500px|Mapping of default stores screenshot]]

This table quickly shows which cache store instances are going to be used for cache types if there are no specific mappings in place. 
To simplify that, this shows the default cache stores for each type.

At the bottom, you will notice there is a link "Edit mappings" that takes you to a page where you can configure this.

==Adding cache store instances==

The default configuration is going to work for all sites, however, you may be able to improve the performance of your sites by making use of various caching backends and techniques. The first thing you are going to want to do is to add cache store instances configured to connect to/use the cache backends you've set up.

===File cache===

[[Image:caching-27-07-add-file-cache-store.png|thumb|300px|Adding a file cache store screenshot]]

When on the cache configuration screen within the ''Installed cache stores'' table you should be able to see the File cache plugin, click ''`Add instance`'' to start the process of adding a file cache store instance.

When creating a file cache there is in fact only one required param, the store name. The store name is used to identify the file store instance in the configuration interface and must be unique to the site.
It can be anything you want, but we would advice making it something that describes your intended use of the file store.

The following properties can also be specified, customising where the file cache will be located, and how it operates.

; '''Cache path''': Allows you to specify a directory to use when storing cache data on the file system. Of course the user the web server is running as must have read/write access to this directory. By default (blank) the Moodledata directory will be used.
; '''Auto create directory''': If enabled when the cache is initialised if the specified directory does not exist Moodle will create it. If this is specified and the directory does not exist the cache will be deemed not ready and will not be used.
; '''Single directory store''': By default, the file store will create a subdirectory structure to store data in. The first 3 characters of the data key will be used as a directory. This is useful in avoiding file system limits it the file system has a maximum number of files per directory. By enabling this option the file cache will not use subdirectories for storage of data. This leads to a flat structure but one that is more likely to hit file system limits. Use with care.
; '''Prescan directory''': One of the features the file cache provides is to prescan the storage directory when the cache is first used. This leads to faster checks of files at the expense of an in-depth read.

The file cache store is the default store used for application caches and by default, the moodledata directory gets used for the cache.
File access can be a taxing resource in times of increased load and the following are some ideas about configuring alternative file stores in order to improve performance.

First up is there a faster file system available for use on your server. 
Perhaps you have an SSD installed but are not using it for your moodledata directory because space is a premium. 
You should consider creating a directory or small partition on your SSD and creating a file store to use that instead of your Moodle data directory.

Next, you've not got a faster drive available for use, but you do have plenty of free space. 
Something that may be worth giving a shot would be to create a small partition on the drive you've got installed that uses a performance orientated file system. 
Many Linux installations these days, for example, use EXT4, a nice file system but one that has overheads due to the likes of journalling. 
Creating a partition and using a file system that has been optimised for performance may give you that little boost you are looking for. Remember caches are designed to be volatile and choosing a file system for a cache is a different decision to choosing a file system for your server. 

Finally, if you're ready to go to lengths and have an abundance of memory on your server you could consider creating a ramdisk/tmpfs and pointing a file store at that.
Purely based in memory, it is volatile exactly like the cache is, and file system performance just isn't going to get much better than this. 
Of course, you will be limited in space and you are essentially taking that resource away from your server.

Please remember with all of these ideas that they are just ideas. 
Whatever you choose - test, test, test, be sure of the decision you make.

===Memcached===

[[Image:caching-27-09-add-memcached-store.png|thumb|300px|Add Memcached store screenshot]]

You must first have a [https://docs.moodle.org/501/en/Performance_recommendations#MemCached Memcached server] you can access and have the [https://docs.moodle.org/501/en/Performance_recommendations#MemCached Memcached PHP extension] installed and enabled on your server.

There are two required parameters in configuring a Memcached store.

; '''Store name''': It is used to identify the store instance in the configuration interface and must be unique to the site.
; '''Servers''': The servers you wish this cache store use. See below for details.

Servers should be added one per line and each line can contain 1 to 3 properties separated by colons.
# The URL or IP address of the server (required)
# The port the server is listening on (optional)
# The weight to give this server (optional)

For example, if you had two Memcached instances running on your server, one configured for the default port, and one configured for 11212 you would use the following:
<code>
127.0.0.1
127.0.0.1:11212
</code>

There are also several optional parameters you can set when creating a Memcached store.

; '''Use compression''': Defaults to true, but can be disabled if you wish.
; '''Use serialiser''': Allows you to select which serialiser gets used when communicating with the Memcached server. By default the Memcached extension and PHP only provide one serialised, however, there is a couple of others available for installation if you go looking for them. One, for example, is the igbinary found at https://github.com/igbinary/igbinary.
; '''Prefix key''': Allows you to set some characters that will be prefixed to all keys before interacting with the server.
; '''Hash method''': The hash method provided by the Memcached extension is used by default here. However, you can select to use an alternative if you wish. http://www.php.net/manual/en/memcached.constants.php provides little information on the options available. Please note if you wish to you can also override the default hash function PHP uses within your php.ini.
; '''Buffer writes ''': Disabled by default, and for good reason. Turning on buffered writes will minimise interaction with the Memcached server by buffering io operations. The downside to this is that on a system with any concurrency there is a good chance multiple requests will end up generating the data because no one had pushed it to the Memcached server when they first requested it. Enabling this can be advantageous for caches that are only accessed in capability controlled areas for example where multiple interactions are taking a toll on network resources or such. But that is definitely on the extreme tweaking end of the scale.

'''Important implementation notes'''

* The Memcached extension does not provide a means of deleting a set or entries. Either a single entry is deleted, or all entries are deleted. 
Because of this, it is important to note that when you purge a Memcached store within Moodle it deletes ALL entries in the Memcached server. Not just those relating to Moodle. 
For that reason, it is highly recommended to use dedicated Memcached servers and to '''NOT''' configure any other software to use the same servers. Doing so may lead to performance depreciation and adverse effects.
* Likewise if you want to use Memcached for caching and for sessions in Moodle it is essential to use two Memcached servers. One for sessions, and one for caching. Otherwise, a cache purge in Moodle will purge your sessions!

===MongoDB===

[[Image:caching-27-10-add-mongodb-store.png|thumb|300px|Add MongoDB store screenshot]]

MongoDB is an open source document orientated NoSQL database. Check out their website www.mongodb.org for more information.

; '''Store name''': Used to identify the store instance in the configuration interface and must be unique to the site.
; '''Server ''': This is the connection string for the server you want to use. Multiple servers can be specified using a comma-separated list.
; '''Database ''': The name of the database to make use of.
; '''Username''': The username to use when making a connection.
; '''Password ''': The password of the user being used for the connection.
; '''Replica set ''': The name of the replica set to connect to. If this is given the master will be determined by using the ismaster database command on the seeds, so the driver may end up connecting to a server that was not even listed.
; '''Use''': If enabled the usesafe option will be used during insert, get, and remove operations. If you've specified a replica set this will be forced on anyway.
; '''Use safe value''': You can choose to provide a specific value for use safe. This will determine the number of servers that operations must be completed on before they are deemed to have been completed.
; '''Use extended keys''': If enabled full key sets will be used when working with the plugin. This isn't used internally yet but would allow you to easily search and investigate the MongoDB plugin manually if you so choose. Turning this on will add a small overhead so should only be done if you require it.

==Mapping a cache to a store instance==

[[Image:caching-27-11-store-mapping.png|thumb|300px|Cache definition store mapping screenshot]]

Mapping a store instance to a cache tells Moodle to use that store instance when the cache is interacted with. This allows the Moodle administrator to control where information gets stored and, most importantly, optimise the performance of your site by making the most of the resources available to your site.

To set a mapping first browse to the cache configuration screen. 
Proceed to find the ''Known cache definitions'' table and within it find the cache you'd like to map.
In the actions column select the link for '''Edit mappings'''.

The screen you are presented allows you to map one or more cache store instances to be used by this cache. 
You are presented with several drop-downs that allow you to map one or more cached. All mapped caches get interacted with. The "Primary" store is the store that will be used first when interacting with the cache.
The "Final" mapped store will be the last cache store interacted with. 
How this interaction occurs is documented below.

If no stores are mapped for the cache then the default stores are used. Have a look at the section below for information on changing the default stores.

If a single store instance is mapped to the cache the following occurs:
; ''Getting data from the cache'': Moodle asks the cache to get the data. The cache attempts to get it from the store. If the store has it, it gives it to the cache, and the cache gives it to Moodle so that it can use the data. If the store doesn't have it, then fail is returned and Moodle will have to generate the data and will most likely then send it to the cache.
; ''Storing data in the cache'': Moodle will ask the cache to store some data, and the cache will give it to the cache store.

If multiple store instances are mapped to the cache the following occurs:
; ''Getting data from a store'': Moodle asks the cache to get the data. The cache attempts to get it from the first store. If the first store has it then it returns the data to the cache and the cache returns it to Moodle. If the first store doesn't have the data then it attempts to get the data from the second store. If the second store has it it returns it to the first store that then stores it itself before returning it to the cache. If it doesn't then the next store is used. This continues until either the data is found or there are no more stores to check.
; ''Storing data in the cache'': Moodle will ask the cache to store some data, the cache will give it to every mapped cache store for storage.

The main advantage of assigning multiple stores is that you can introduce cache redundancy. Of course, this introduces an overhead so it should only be used when actually required.
The following is an example of when mapping multiple stores can provide an advantage:
<pre>
Scenario:
You have a web server that has a Moodle site as well as other sites.
You also have a Memcached server that is used by several sites including Moodle.

Memcached has a limited size cache, that when full and requested to store more information frees space by dropping the least used cache entries.

You want to use Memcached for your Moodle site because it is fast, however, you are aware that it may introduce more cache misses because it is a heavily used Memcached server.

Solution:
To get around this you map two stores to caches you wish to use Memcached.
You make Memcached the primary store, and you make the default file store the final cache store.

Explanation:
By doing this you've created redundancy; when something is requested, Moodle first tries to get it from Memcached (the fastest store) and if it is not there it proceeds to check the file cache.
</pre>

Just a couple more points of interest:

* Mapping multiple caches will introduce overhead, the more caches mapped the more overhead.
* Consider the cache stores you are mapping to, if data remains there once set then there is no point mapping any further stores after it. This technique is primarily valuable in situations where data is not guaranteed to remain after being set.
* Always test your configuration. Enable the display of performance information and then watch which stores get used when interacting with Moodle in such a way as to trigger the cache.

==Setting the stores that get used when no mapping is present==

[[Image:caching-27-12-default-store-mapping.png|thumb|300px|Setting which stores get used when no mapping is present screenshot]]

This is really setting the default stores that get used for a cache type when there is not a specific mapping that has been made for it.

To set a mapping first browse to the cache configuration screen. 
Proceed to find the ''Stores used when no mapping is present'' table. 
After the table you will find a link '''Edit mappings''', click this.

On the screen you are presented with you can select one store for each cache type to use when a cache of the corresponding type gets initialised and there is not an explicit mapping for it.

Note that on this interface the drop downs only contain store instances that are suitable for mapping to the type.
Not all instances will necessarily be shown. If you have a store instance you don't see then it is not suitable for '''ALL''' the cache definitions that exist. 
You will not be able to make that store instance the default, you will instead need to map it explicitly to each cache you want/can use it for.

==Configuring caching for your site==

This is where it really gets tricky, and unfortunately, there is no step-by-step guide to this.

How caching can be best configured for a site comes down entirely to the site in question and the resources available to it.

What can be offered are some tips and tricks to get you thinking about things and to perhaps introduce ideas that will help you along the way.

If you are reading this document and you've learnt a thing or two about configuring caching on your site share your learnings by adding to the points here.

* Plan it. It's a complex thing. Understand your site, understand your system, and really think how users will be using it all.
* If you've got a small site the gains aren't likely to be significant, if you've got a large site getting this right can lead to a substantial boost in performance.
* When looking at cache backends really research the advantages and disadvantages of each. Keep your site in mind when thinking about them. Depending upon your site you may find that no one cache backend is going to meet the entire needs of your site and that you will benefit from having a couple of backends at your disposal.
* Things aren't usually as simple as installing a cache backend and then using it. Pay attention to configuration and try to optimise it for your system. Test it separately and have an understanding of its performance before telling Moodle about it. The cache allows you to shift load off the database and reduce page request processing. If for instance you have Memcached installed but your connection has not been optimised for it you may well find yourself in a losing situation before you even tell Moodle about the Memcached server.
* When considering your default store instances keep in mind that they must operate with data sets of varying sizes and frequency. For a large site really your best bet is to look at each cache definition and map it to a store that is best suited for the data it includes and the frequency of access. Cache definitions have been documented [[Cache definitions]].
* Again when mapping store instances to caches really think about the cache you are mapping and make a decision based upon what you understand of your site and what you know about the cache. Cache definitions have been documented [[Cache definitions]].
* Test your configuration. If you can stress test it even better! If you turn on performance information Moodle will also print cache access information at the bottom of the screen. You can use this to visually check the cache is being used as you expect, and it will give you an indication of where misses etc are occurring.
* Keep an eye on your backend. Moodle doesn't provide a means of monitoring a cache backend and that is certainly something you should keep an eye on. Memcached for instance drops least used data when full to make room for new entries. APC, on the other hand, stops accepting data when full. Both will impact your performance if full and you're going to encounter misses. However APC when full is horrible, but it is much faster.

===More on performance testing===

Two links that might be useful to anyone considering testing performance on their own servers:

* [http://www.iteachwithmoodle.com/2012/10/12/moodle-performance-testing-how-much-more-horsepower-do-each-new-versions-of-moodle-require/ Moodle performance testing: how much more horsepower do each new versions of Moodle require?]
* [http://www.iteachwithmoodle.com/2012/10/11/how-to-stress-test-your-moodle-server-using-loadstorm/ How to load test your Moodle server using Loadstorm]

===Performance advice for load-balanced web servers===

# In Moodle 2.4 onwards with load-balanced web servers, don't use the default caching option that stores the data in moodledata on a shared network drive. Use memcached instead. See Tim Hunt's article on http://tjhunt.blogspot.de/2013/05/performance-testing-moodle.html
# In Moodle 2.6 onwards make sure you set $CFG->localcachedir to some local directory in config.php (for each node). This will speed up some of the disk caching that happens outside of MUC, such as themes, javascript, libraries etc.

==Troubleshooting==

Have you encountered a problem, or found yourself in a conundrum? Perhaps the answer is in this section. If not when you find an answer, how about you share it here.

==More information==
* [[Cache definitions]] Information on the cache definitions found within Moodle.
* [[:dev:Cache API|Cache API]] Details of the Cache API.
* [[:dev:Cache API - Quick reference|Cache API - Quick reference]] A short, code focused page of on the Cache API.
* [[:dev:The Moodle Universal Cache (MUC)|The Moodle Universal Cache (MUC)]] The original cache specification.

Cache related forum discussions that may help in understanding MUC:
* [https://moodle.org/mod/forum/discuss.php?d=217195 MUC is here, now what?]
* [https://moodle.org/mod/forum/discuss.php?d=226123 Status of MUC?]
* [https://moodle.org/mod/forum/discuss.php?d=222250 Putting cachedir on local disks in cluster]
* [https://moodle.org/mod/forum/discuss.php?d=232122 moodle cachestore_file]
* [https://moodle.org/mod/forum/discuss.php?d=378416#p1526130 Why using a not-completely-shared application cache will fail]

Other:
* [http://jfilip.ca/2013/08/20/moodle-2-4-5-vs-2-5-1-performance-and-muc-apc-cache-store/ Moodle 2.4.5 vs. 2.5.1 performance and MUC APC cache store] blog post by Justin Filip

==See also==

* [[MUC FAQ]]

[[de:Caching]]
[[es:Cacheando]]
[[fr:Mettre en cache]]
[[ja:キャッシング]]

MUC FAQ

2020-03-19T15:01:33Z

Mits: ja link

{{Performance}}
The Moodle Unified Cache (MUC) on initial inspection can appear to be a complex off-putting beast and this can lead to it either being ignored or, as is often the case, poorly configured.

Here is what you need to know (so you can ignore [[Caching| the rest]]).

==What is the MUC?==

The MUC is a cache, a cache is a store of data which is easier/faster to retrieve than if it came from it's source. It saves (computing) effort and makes Moodle faster.

==Should I be using the MUC?==

Yes, and sites running Moodle 2.4 or above are already using the MUC.

If a site is already running fine then consider '''not changing anything''' as "[https://en.wikipedia.org/wiki/Program_optimization#When_to_optimize premature optimization is the root of all evil]".

By default MUC uses the file system to store it's cached objects, this already speeds thing up greatly compared to using no MUC at all. By further configuring the MUC we are just trying to make it faster.

==What is wrong with the default file-system MUC?==

Not much at all, but the MUCs performance is dependant on the read/write speed of its storage medium.

Typically disks are slow but safe (persistent) storage. MUC data does not need to kept safe as it can always be regenerated and so can afford to be kept somewhere fast yet volatile, like RAM.

==How can I make MUC faster?==

Using a RAM based cache is the best way to make the MUC fast and there a few tools we can use to do this, such as, tmpfs, Memcached, APC, Redis and overtime probably more... A good place to start if unsure of any specific requirements is Memcached as it is common, well tested, fast and easy to deploy.

==How do I deploy Memcached==

This is by no means exhaustive, and will vary depending on the OS etc. But for simplicities sake...

* Install Memcached and it's PHP support in a way compatible with the operating system e.g. in Debian/Ubuntu
apt-get install memcached php5-memcached
* Confiure Memcached, or at least become aware of it's default setup, e.g.
** 64MB of RAM allocation
** Runs on port 11211
* In Moodle go to
**'Site administration > Plugins > Caching > Configuration'
**Under '''Installed cache stores''' look for Memcached and click the '''Add instance''' action.
**Give the store a name, like 'Memcached_MUC'
**In '''server''', assuming the basic config above, type 'localhost'. '''Save Changes'''.
**Scroll to the bottom of the '''Cache administration''' page.
**Under '''Stores used when no mapping is present''' click '''Edit Mappings'''.
**In the '''Application''' drop down select the caches name. '''Save Changes'''.
* Profit

See [[Caching]] for more details.

==How much memory should I allocate to MUC?==

The default on most Memcached deployments is 64MB and this is probably '''more''' than enough for a standard Moodle install. As a real world example, checking a live site with ~6000 individual user logins over the last 24 hours, was Memcached MUC usage was ~11MB (Moodle 2.8 with 26 additional plugins).

Most importantly when implementing an in memory cache such as Memcached is to monitor and understand its use in '''your own''' deployment as requirements can vary wildly.

==I'm already using Memcached for sessions, can I just reuse that?==

Nope, afraid not. If the MUC purges so will sessions, all users will be logged out. Two Memcached instances are required in this scenario, one for sessions and one MUC. An example of how to do this can be found [https://moopi.uk/course/view.php?id=4#section-5 here].

==How can I tell what Cache store I am really using==
[[File:perf.png|thumb|300px]]
Temporarily switch on performance debugging at,

''Site administration Development > Debugging > Performance info''.

This adds some useful information to the the footer of all pages (if your theme supports it) including MUC objects and the cachestore they came from .

==I have a cluster of servers, <further question here>?==

You are probably beyond the target audience of this FAQ in terms of your system administration foo.

==What is that little grey triangle?==
[[File:muc-triangle.png|thumb|300px]]
This appears under '''Stores used when no mapping is present''' when the default Application Cache store mapping does not support a requirement of one or more of the cache definitions.

For example, of the default application caches, '''Event Invalidation''' is not supported by Memcached. This is because Event Invalidation requires '''Data Guarantee''' which ensures data exists in the cache once it is put there. It is never cleaned up to free space or because it has not been recently used. Because Memcached evicts objects from it's cache it cannot be used for Event Invalidation.

This is not a problem as Event Invalidation will simply use the file-system cache, or if specified a compatible secondary application cache, or one allocated directly to the Event Invalidation definition.

==Where can I find more documentation on setting up the MUC?==

See [[Caching]].

If you are further interested in the nuts and bolts of the caching system, e.g. cache features (ttl, data guarantee, etc) the [https://github.com/moodle/moodle/blob/master/cache/README.md developers api] is a good place to look.

==See also==

* [https://moodle.org/mod/forum/discuss.php?d=323628 MUC and localcache] forum discussion

[[de:MUC FAQ]]
[[es:MUC FAQ]]
[[fr:FAQ sur Moodle Unified Cache]]
[[ja:MUC_FAQ]]

Cache definitions

2020-02-26T15:02:38Z

Mits: ja link

{{Performance}}
This page contains information on the cache definitions within core. This information will likely be of most use to those administrators who are really trying to get the most out the caching system in Moodle. The information about each cache should help in deciding which backends to use for which definitions.

For small sites, or those running on a single server likely adopting a single backend such as memcache is going to give you an immediate performance boost. 
However with a bit of planning and some careful mapping likely you can improve things further.

==What you will find in this document==
Each cache definition found within core will be under its own heading and will include a description of the cache. 
As well as the name and description the following information will also be details:

'''Since:''' When this cache definition was first introduced into Moodle.
 '''Component/Area:''' The code component this cache belongs to and the area (unique simple name) given to it.
 '''Growth:''' Will state if this cache is expected to be of fixed size, or can be expected to grow as the site data grows. Perhaps some information on how the cache will grow.
 '''Who:''' Which users can expect to benefit from the cache.
 '''Priority:''' An indication of the anticipated cache use on a site. A value between 1 and 5. If the cache is of fixed size and is accessed expected to be utilised on every page it will be given a 5 for priority as it can be expected that assigning that cache to the fastest backend available would be the good idea. In contrast a priority of 1 would be given to a cache that is expected to grow quickly, is only accessed on specific pages, and only applies to some users (e.g. teachers, or the admin). This cache should be the least of your concerns when deciding upon how to implement caching on your site.

==A note about cache configuration on large sites==
Each different cache can be configured independently, allowing admins to "tune" their setup for particular systems. 
By default these caches are all set to use the file system, which is usually fine on a small one-server system.

On a cluster, however, these defaults can cause problems because shared filesystems are slow, so in these cases we recommend you use a faster shared caching backend like memcached instead. Note that most of these caches operating under the assumption that they are shared. 
In some cases you can choose to use a non-shared cache like the local filesystem however in these instances you be careful to purge caches MANUALLY as part of system administration.

==Application caches==
Application caches are shared caches.

Why '''must''' they be be shared? See the [https://moodle.org/mod/forum/discuss.php?d=378416#p1526130 Can Redis Shared Application cache run on local nodes?] discussion in the Using Moodle forum.

===Accumulated information about modules and sections for each course===

Accumulated information about course modules, and sections used to print the course page as well as in calls to ''get_fast_modinfo()''. 
This cache gets forcefully reset within ''rebuild_course_cache()''.

This is an excellent cache to optimise caching for on a production site. 
It is accessed primarily for the course view page, and very frequently hit and often expensive page and it is utilised within ''get_fast_modinot()'' a function that is called often in Moodle when querying or displaying information on a course, section or activity.

'''Since:''' Moodle 2.6
 '''Component/Area:''' core, coursemodinfo
 '''Growth:''' exponential, the number of courses, sections within those courses, and activities within each section will determine the size of this cache.
 '''Who:''' everyone. This cache isn't accessed on every page, however as its associated with courses you can expect its accces to still be high.
 '''Priority:''' 4

===Calendar subscriptions===

Caches calendar subscriptions. 
This is a very simple cache that stores the calendar subscription records from the database for quick, specific access.

This should be considered a low priority cache unless your users are likely to be creating many calendar subscriptions. 
The actual data being stored is going to be very small, should you have lots of calendar subscriptions mapping this cache definition to a fast, but small backend would be ideal.

'''Since:''' Moodle 2.5
 '''Component/Area:''' core, calendar_subscriptions
 '''Growth:''' determined by the number of calendar subscriptsion created by users. Entirely dependent on your users.
 '''Who:''' everyone who has a calendar subscript, on calendar pages, or pages where the calendar block is being displayed.
 '''Priority:''' 1

'''Notes for advanced, multi-server sites'''

* What is cached:- Record entries from 'event_subscriptions' table, representing various calendar subscriptions.
* When the cache is updated:- When a calendar subscription is updated or deleted.
* How often it is hit:- Everytime a calendar subscription detail is fetched.
* When should the cache be purged completely:- This should not be needed.

===Concept linking [mod_glossary]===

Caches concepts for the glossary filter.

Concepts are cached in relation to either the site or a course. The course ID is used as the key if they are for a course, 0 is used as the key for site concepts. 
Each entry in the cache is an array consisting of two items, the first is an array of glossaries, the second an array of concepts. 
The actual data being stored is minimal, even on a large site the storage requirement for this cache should be relatively small.

'''Important''' This cache CANNOT be a local cache, it must be shared.

'''Since:''' Moodle 2.7 (MDL-44366)
 '''Component/Area:''' mod_glossary, concepts
 '''Growth:''' exponential, the number of glossaries, and the number of terms within those glossaries will determine the size of this cache.
 '''Who:''' everyone when the glossary filter is enabled.
 '''Priority:''' 3

===Config settings===

Caches the configuration for the site. This is the administration settings in both core and all plugins.

This cache is going to be accessed on every single page within Moodle, regradless of the users state or what is being done. 
You should map this cache to the fastest backend you've got available.

'''Since:''' Moodle 2.4
 '''Component/Area:''' core, config
 '''Growth:''' fixed, the number of items is the number of settings in core and all installed plugins. This will only increase as settings are introduced or removed.
 '''Who:''' everyone, on every page, without fail.
 '''Priority:''' 5

'''Notes for advanced, multi-server sites'''

* Requires shared cache.
* This cache is hit quite often for getting config settings.

===Course categories tree===

This cache stores the full course categories tree.

It is often used when navigating the course category structure and you can expect it to be hit in situations where either the full tree, or part of the tree is displayed. 
This includes some elements that can be configured to display on the front page. 
Its use will be determinent on how you have configured Moodle and what is set to be displayed.

'''Since:''' Moodle 2.5 (MDL-38147)
 '''Component/Area:''' core, coursecattree
 '''Growth:''' fixed, will be limited to the number of course categories on your site. During course creation this site will obviously grow, but in day to day use it should remain static.
 '''Who:''' everyone.
 '''Priority:''' 3

'''Notes for advanced, multi-server sites'''

* Requires shared cache.
* Gets invalidated when changesincoursecat event is triggered.

===Course group information===

Caches grouping information for courses.

Information is cached in relation to a course and is very simple. It is only used in situations where a course has defined groups and those groups are being used. 
This cache can be expected to save 1 - 2 queries per page. 

'''Since:''' Moodle 2.5 (MDL-34398)
 '''Component/Area:''' core, groupdata
 '''Growth:''' fixed, the number of courses and groups within those courses determines the size of this cache.
 '''Who:''' all users accessing a course in which groups are used.
 '''Priority:''' 2

'''Notes for advanced, multi-server sites'''

* Gets updated when groups data is fetched for a course.
* Requires shared cache.

===Database meta information===

Caches meta information on database tables including information about columns.

This cache is a priority cache, it is accessed on nearly every page within Moodle and its operation can be expensive. 
Each entry uses the table name as the key and the cached data is the structure of the database table.

'''Since:''' Moodle 2.4 (MDL-25290)
 '''Component/Area:''' core, databasemeta
 '''Growth:''' fixed, the number of database tables determines the size of this cache and may only change during upgrade and installation/deletion of plugins.
 '''Who:''' everyone
 '''Priority:''' 5

'''Notes for advanced, multi-server sites'''
* Requires shared cache
* If not shared, caches need to be invalidated after any DB structure change including creation of temporary tables.

===Event invalidation===

This cache is used to manage event invalidation for the MUC API. This is an internal API and has no relation what so ever to the Event API introduced in 2.7.

This is not often used within Moodle and when it is used occurs when editing happens and multiple caches need to purged, not all of which may be shared and some which may be cleared when the user next touches the cache.
The overall cache size should be relatively small, and as checking often occurs for these caches on page access it is recommended to map this cache to a fast backend.

'''Since:''' Moodle 2.4 (MDL-25290)
 '''Component/Area:''' core, eventinvalidation
 '''Growth:''' fixed, events are subscribed to by definitinos and will only change during upgrade and the installation and deletion of plugins.
 '''Who:''' everyone, events get triggered by action and in disconnected caches this be not be reflected until the user next hits the page.
 '''Priority:''' 4

'''Notes for advanced, multi-server sites'''
* Whenever something is invalidated, it is purged immediately and an event record is created with the timestamp.
* Requires shared cache.

===Event observers===

This cache is used for storing list of event observers.

It is updated on install/update while initialising list of event observers. 
This cache is accessed, when event is trigged.

'''Since:''' Moodle 2.6 (MDL-39846)
 '''Component/Area:''' core, observers
 '''Growth:''' ?
 '''Who:''' ?
 '''Priority:''' ?

'''Notes for advanced, multi-server sites'''

* Requires shared cache.

===External badges for particular user===

Used to store external badges.

'''Since:''' Moodle 2.5.2, 2.6 (MDL-40924)
 '''Component/Area:''' core, externalbadges
 '''Growth:''' ?
 '''Who:''' ?
 '''Priority:''' ?

===Grade items cached for evaluating conditional availability [availability_grade, items]===

Used to cache course grade items for conditional availability purposes.

'''Note:''' This cache sets a TTL (Time To Live) of 3600 (1 hour).

'''Since:''' Moodle 2.7 (MDL-44070)
 '''Component/Area:''' availability_grade, items
 '''Growth:''' ?
 '''Who:''' ?
 '''Priority:''' ?

===HTML Purifier - cleaned content===

This is a cache of texts (forum posts, resources, intros etc etc) from all parts of Moodle, after it has been cleaned of possible malicious data.

Caches cleaned text in relation to user + context of the text being cleaned.

'''Tip:''' This data may be safetly stored in local caches on clusted nodes.

'''Since:''' Moodle 2.4.2, 2.5 (MDL-36297)
 '''Component/Area:''' core, htmlpurifier
 '''Growth:''' exponential, cleaned content is usually stored once for each user + context combination.
 '''Who:''' everyone
 '''Priority:''' 3

'''Notes for advanced, multi-server sites'''

In Moodle 2.5,
* This expects a shared cache
* If not shared, must be manually purged after every upgrade or change of $CFG->allowobjectembed setting

In Moodle 2.6 and later,
* This works fine with local or shared node caches, you don't have to do anything special.

===Language string cache===

The language string cache is one of the most essential caches within Moodle, it caches each and every language file used within Moodle. 
Its of fixed size as there are a finite number of languages and language files and as it is accessed one pretty much every page within Moodle. 
This is a prime cache to configure, map it to the fastest backend you've got available.

The string cache uses the a hash of the revision, language, and component of a language file as the key, and the array found within the corrosponding file is the data. 
Static acceleration is used on this cache to speed up subsequent request for a string within a given language file. This is essential as string are usually requested one by one and often only from a handful of language files.

'''Tip:''' Cache usage differs greatly between Admins + managers and teacher + students. Admins and managers being able to complete more actions and often across difference components and plugins often require that many more language files be accessed for a page than a user such as a teacher or student require. 
When testing your cache configuration ensure you test as a student.

'''Since:''' Moodle 2.4 (MDL-25290)
 '''Component/Area:''' core, string
 '''Growth:''' fixed size, each language string file is cached here, its size will be fixed but will be determined by the number of languages available on your site.
 '''Who:''' everyone, on every browsable page within Moodle.
 '''Priority:''' 5

'''Notes for advanced, multi-server sites'''

* If shared between sites please be aware that any language customisations will also be shared.

In Moodle 2.4 and Moodle 2.6:
* Expects shared cache.
* If not shared it must be manually purged after any language string change such as editing of local lang packs, updating of lang packs during upgrade, installation or uninstallation of languages.

In Moodle 2.6 and later:
* Works fine with local or shared node caches, you don't have to do anything special.

===List of available languages===

Caches a list of available languages.

This list of languages is used every time the list of languages is requested in a page. 
Because of this the cache will be hit by on many pages within Moodle on any site with more than one language installed.
As its a small, fixed size cache on a site with multiple languages installed its a good idea to map this to the fastest backend you've got available.

'''Since:''' Moodle 2.6 (MDL-41019)
 '''Component/Area:''' core, langmenu
 '''Growth:''' fixed, determined by the number of languages installed on the site.
 '''Who:''' everyone
 '''Priority:''' 4

===List of course contacts===

Used to cache course contacts.

Course contacts are displayed in several places throughout Moodle, they are in most situations considered public information (like course names) and can be seeing by all users. 
The process of listing these course contacts can be expensive, however the course contacts are shown only on select pages.

'''Since:''' Moodle 2.5 (MDL-38596)
 '''Component/Area:''' core, coursecontacts
 '''Growth:''' the number of courses and the number of users with course contact roles determines this size of this cache.
 '''Who:''' everyone, course contacts are public information and may be displayed in several places throughout Moodle that can be accessed by anyone.
 '''Priority:''' 3

'''Notes for advanced, multi-server sites'''

* This is accessed while rendering/searching course
* Requires shared cache.

===Plugin info manager===

Caches information on installed plugins, enabled plugins, and present plugins.

This cache is heavily used when managing plugins for site through the admin interfaces. 
Primarily people accessing this page benefit from the existence of this cache.

'''Note:''' This must be a shared cache.

'''Since:''' Moodle 2.5 (MDL-34401)
 '''Component/Area:''' core, plugin_manager
 '''Growth:''' fixed, the number of plugins determines the size of this cache.
 '''Who:''' Administrators primarily.
 '''Priority:''' 2

====Plugin info - base====
* This cache is used by plugininfo_base class and stores plugin information.
* This is accessed while loading/checking plugin versions from disk.
* Requires shared cache.

====Plugin info - activity modules====
* This cache is used by plugininfo_mod class and provide access to records in modules table.
* This is accessed while loading/checking modules.
* Requires shared cache.

====Plugin info - blocks====
* This cache is used by plugininfo_block class and provide access to records in block table.
* This is accessed while loading/checking blocks.
* Requires shared cache.

====Plugin info - filters====
* This cache is used by plugininfo_filter class and stores names of all filters installed.
* This is accessed while loading/checking installed filters.
* Requires shared cache.

====Plugin info - repositories====
* This cache is used by plugininfo_repositories class and provide access to records in repository table.
* This is accessed while loading enabled repositories.
* Requires shared cache.

====Plugin info - portfolios====
* This cache is used by plugininfo_portfolio class and stores list of enabled portfolio plugins.
* This is accessed while checking if portfolio is enabled.
* Requires shared cache.

===Question definitions===

Caches question definitions. This is used by the question bank class.

'''Since:''' Moodle 2.4 (MDL-34399)
 '''Component/Area:''' core, questiondata
 '''Growth:''' ?
 '''Who:''' ?
 '''Priority:''' ?

'''Notes for advanced, multi-server sites'''
* This gets updated when question is loaded or edited.
* Doesn't require data guarantee.
* Requires shared cache.

===User grades cached for evaluating conditional availability===

'''Since:'''
 '''Component/Area:''' core, gradecondition
 '''Growth:'''
 '''Who:'''
 '''Priority:'''

===User grades cached for evaluating conditional availability [availability_grade, scores]===

Used to cache user grades for conditional availability purposes.

'''Note:''' This cache sets a TTL (Time To Live) of 3600 (1 hour).

'''Since:''' Moodle 2.7 (MDL-44070)
 '''Component/Area:''' availability, scores
 '''Growth:''' ?
 '''Who:''' ?
 '''Priority:''' ?

===YUI Module definitions===

Caches information on shifter YUI modules used within Moodle when JS caching is enabled.

'''Since:''' Moodle 2.5 (MDL-38391)
 '''Component/Area:''' core, yuimodules
 '''Growth:''' fixes, the number of Moodle YUI modules within core and plugins. This will only change during upgrade, or installation/removal of plugins.
 '''Who:''' everyone, this is used when ever Moodle YUI modules are used on a page and that is most pages as of 2.8.
 '''Priority:''' 5

'''Notes for advanced, multi-server sites'''

* Requires shared cache.

==Session caches==
Data cached here belongs to the user browsing the site.

===Course categories lists for particular user===

Used to store data for course categories visible to current user. Helps to browse list of categories. 
This is also used during course category management.

'''Since:''' Moodle 2.5 (MDL-38147)
 '''Component/Area:''' core, coursecat
 '''Growth:''' the number of categories and courses on the site that the user can see will determine the size of this for the current user.
 '''Who:''' everyone, it is used within several front page elements.

'''Notes for advanced, multi-server sites'''

* Requires shared cache.
* Is invalidated when changesincoursecat or changesincourse event is trigged.

===Data used to persist user selections throughout Moodle===

Caches user selections that should persist for the lifetime of the users log in. This includes things like which categories the user has expanded in the course category management page. 
Think of them like user preferences but with limited lifetime.

'''Since:''' Moodle 2.6 (MDL-42299)
 '''Component/Area:''' core, userselections
 '''Growth:''' exponential, depends upon how much the user interacts with things like expading categories.
 '''Who:''' logged in users.

===Folder name cache [repository_skydrive]===

?

'''Since:''' Moodle 2.6 (MDL-30740)
 '''Component/Area:''' repository_skydrive, foldername
 '''Growth:''' ?
 '''Who:''' ?
 '''Priority:''' ?

==Request caches==
Caches here last only for the life time of the request and are only available to the browsing user.

===Course categories records===

Caches a list of course categories visible to the user.

'''Since:''' Moodle 2.5 (MDL-38147)
 '''Component/Area:''' core, coursecatrecords
 '''Growth:''' fixes, the number of categories on the site visible to the user will determine this.
 '''Who:''' everyone

'''Notes for advanced, multi-server sites'''

* This is accessed while rendering course category.
* Is invalidated when changesincoursecat event is triggered.
* Require local cache.

===Helper caching [tool_uploadcourse]===

'''Since:''' Moodle 2.6 (MDL-13114)
 '''Component/Area:''' tool_uploadcourse, helper
 '''Growth:''' ?
 '''Who:''' Administrators
 '''Priority:''' ?

===Repositories instances data===

Used to cache data on configured repositories to avoid repetitive database calls to load repositories.

'''Since:''' Moodle 2.5 (MDL-34346)
 '''Component/Area:''' core, repositories
 '''Growth:''' ?
 '''Who:''' logged in users with one or more accessible repositories.
 '''Priority:''' ?

'''Notes for advanced, multi-server sites'''

* Requires local cache.

==More information==
* [[Cache definitions]] Information on the cache definitions found within Moodle.
* [[:dev:Cache API|Cache API]] Details of the Cache API.
* [[:dev:Cache API - Quick reference|Cache API - Quick reference]] A short, code focused page of on the Cache API.
* [[:dev:The Moodle Universal Cache (MUC)|The Moodle Universal Cache (MUC)]] The original cache specification.

==See also==

* MDL-59142 - Cache post-processed CSS in MUC

[[ja:キャッシュ定義]]

Recycle bin

2018-10-16T15:03:34Z

Mits: ja link

{{More features}}
==What is the recycle bin?==
*The recycle bin allows teachers to retrieve course elements they have mistakenly deleted. It also allows those with relevant category permissions to restore deleted courses.
*If deleted items are not needed, they are automatically permanently deleted after seven days (or a time specified by the admin.)
*The recycle bin was the first project funded by the [https://moodleassociation.org/ Moodle Users Association].

{{MediaPlayer | url = https://www.youtube.com/watch?v=Wzieh7BYwfE | desc = Recycle bin in Moodle 3.1}}

==How does it work?==
===Deleted activities===

1. Before a course teacher deletes an item, a reminder message appears:

[[File:confirmdeletion.png]]

2. If you mistakenly click 'yes', all is not lost. After a short while, a 'Recycle bin' link will appear either via the gear menu or in the Administration block (depending upon your theme). (The delay in the 'Recycle bin' link appearing is because it requires the [[Cron|cron]] to run and the page to be refreshed.)

[[File:courseadminrecylebinlink.png]]

3. Click the link and then click the 'restore' icon to retrieve the assignment or other item you accidentally deleted.

[[File:recycle bin.png]]

===Deleted courses===
1. Access the category that the course was in before you accidentally deleted it.
2. From the category administration block, click 'Recycle bin'.

[[File:recyclebinrestorecourse1.png]]

3.Click 'Restore' to restore the deleted course:

[[File:recyclebinrestorecourse2.png]]

==Activity deletion in progress==

A message 'Activity deletion in progress...' is displayed whilst an activity is being deleted.

Note: The [[Cron|cron]] should run every minute to ensure that activities are deleted promptly.

==How is it set up?==
*The recycle bin is available by default in all courses and categories, but the link in the administration block is only visible once something has been deleted.
*Administrators can modify the settings from "Recycle bin'' in the Site administration, and can decide how long an item or a course will remain available until it is permanently deleted, and make the recycle bin visible in the administration block even when empty. If preferred, the recycle bin can be disabled.

==See also==

* [https://moodle.org/mod/forum/discuss.php?d=364368 Can't remove Deletion in progress activities Moodle 3.4] forum discussion

[[es:Papelera de reciclaje]]
[[de:Papierkorb]]
[[ja:ゴミ箱]]

Installation quick guide

2018-09-09T15:17:02Z

Mits: ja link

{{Installing Moodle}}
''This page is intended for administrators who are experienced with installing web server applications and are in a hurry to get up and running. Otherwise please see [[Installing Moodle]]''.

==Basic Requirements==

* You will need a working web server (e.g. [[Apache]]), a database (e.g. [[MySQL]], [[MariaDB]] or [[PostgreSQL]]) and have [[PHP]] configured. See the [{{Release notes}} release notes] in the dev docs for software requirements.
* Moodle requires a number of [[PHP]] extensions. However, Moodle checks early in the installation process and you can fix the problem and re-start the install script if any are missing.
* If you want Moodle to send email (you probably do) you need a working Sendmail (Unix/Linux) on your server or access to an SMTP mail server.

==Getting Moodle==

You have two basic options:
* Download your required version from http://moodle.org/downloads ... OR
* Pull the code from the Git repository (recommended for developers and also makes upgrading very simple):
<pre>
git clone -b MOODLE_35_STABLE git://git.moodle.org/moodle.git
</pre>
...this fetches a complete copy of the Moodle repository and then switches to the {{Version}} Stable branch.

See [[Git_for_Administrators|Git for Administrators ]] for details on using Git to install Moodle code.

Note: Only download Moodle from one of the moodle.org sources. Other versions (e.g. control panel based installers, Linux distribution repositories, other "one click" installers) cannot be guaranteed to work properly, be upgradable or be supportable.

==Create a database==

* Using your chosen database server, create a new empty database. The default encoding must be UTF8. For example, using MySQL:
<pre>
CREATE DATABASE moodle DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
</pre>
* Create a user/password combination with appropriate permissions for the database. For example (MySQL again):
<pre>
mysql> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,CREATE TEMPORARY TABLES,DROP,INDEX,ALTER ON moodle.* TO 'moodleuser'@'localhost' IDENTIFIED BY 'yourpassword';
</pre>

Notes: It is important to GRANT ON moodle.* as the database name including the '.*' and not just the bare database name. Save this password you use for the Moodle user, since you will need it later in the install.

==Create data directory==

* Create an empty directory to hold Moodle files. It '''must not''' be in the area served by the web server and must have permissions so that the web server user can write to it. Other than that it can be located anywhere. Typically, either make it owned by the web server user or give it write permissions for 'everyone'. If it is on a shared/NFS drive then read [[Caching]] - Moodle caches to this disk area by default and a slow share will mean terrible performance.

==Install Moodle code==

* If you downloaded the zip or tgz file earlier, then unzip / untar / move / copy the Moodle code (obtained above) so that it will be served by your web server (e.g. on Debian based Linux, move to /var/www/html/moodle)
* Check the permissions and make sure that the web server does '''not''' have permissions to write to any of the files in the Moodle code directories (a very common root cause of sites being hacked).
* If you need to, configure your web server to serve the Moodle site with your chosen URL.

==Configure Moodle==

* In the Moodle code directory, find the file ''config-dist.php'' and copy it to a new file called ''config.php'' (but read next step, 'Install Moodle', first).
* Edit config.php with your favourite editor and change the appropriate settings to point to your site, directories and database. ''Note: the Moodle install script will create config.php for you if it does not exist but make sure you (re-)set permissions appropriately afterwards''

==Install Moodle==

* Go to the URL for your moodle site in a browser (installation will complete automatically) or run the command line version at (requires cli version of PHP):
<pre>
/usr/bin/php /path/to/moodle/admin/cli/install.php
</pre>
The CLI creates the config.php for you and will not run if you created one in the previous step.
* After completing the install make sure your file permissions are ok for the Moodle program files (not writeable by web server) and the Moodle data files (writeable by web server).

==Set up cron==

You will need a cron job to run periodically. It is recommended that ''the cron is run every minute'', as required for asynchronous activity deletion when using the [[Recycle bin|recycle bin]]. A typical Unix cron entry will be as follows:
<pre>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php >/dev/null
</pre>
Your site '''will not work properly''' unless cron is running regularly. It is very important you do not skip this step.

See [[Cron]] for details.

==Congratulations!==

You are now ready to use your Moodle site.

If you run into problems, check the [[Installation FAQ]] and visit the [http://moodle.org/mod/forum/view.php?id=28 Installation help forum].

[[Category:Quick guide]]

[[de:Installation in Kürze]]
[[fr:Installation_rapide]]
[[es:Inicio_Rápido_de_Instalación]]
[[ja:インストレーションクイックガイド]]

MariaDB

2018-08-10T13:26:19Z

Mits: ja link

MariaDB is a MySQL fork that is developed and maintained by original MySQL developers organised under MariaDB Foundation. It is considered to be more open and is being distributed as default MySQL compatible database by majority of modern linux distributions.

MariaDB is a drop-in replacement for Oracle MySQL, you can use it with any stable supported Moodle version using standard mysqli drivers.

==MariaDB driver==

There is a dedicated driver for MariaDB. It is recommended to explicitly specify mariadb Moodle driver in config.php:

<code php>
$CFG->dbtype = 'mariadb';
$CFG->dblibrary = 'native';
</code>

At the moment the driver is similar to MySQL but in the future the implementations may diverge significantly. Moodle MariaDB driver is not compatible with MyISAM database engine.

See [[MySQL]] for more information, the setup procedure is nearly identical.

==FAQ==
It fails during installation due to binlog_format configuration:
In my.cnf file set binlog_format = ROW under [mysqld] and restart mysql service

==See also==
* [https://mariadb.org MariaDB.org]

[[ja:MariaDB]]

Installation quick guide

2018-07-13T13:04:14Z

Mits:

{{Installing Moodle}}
''This page is intended for administrators who are experienced with installing web server applications and are in a hurry to get up and running. Otherwise please see [[Installing Moodle]]''.

==Basic Requirements==

* You will need a working web server (e.g. [[Apache]]), a database (e.g. [[MySQL]], [[MariaDB]] or [[PostgreSQL]]) and have [[PHP]] configured. See the [{{Release notes}} release notes] in the dev docs for software requirements.
* Moodle requires a number of [[PHP]] extensions. However, Moodle checks early in the installation process and you can fix the problem and re-start the install script if any are missing.
* If you want Moodle to send email (you probably do) you need a working Sendmail (Unix/Linux) on your server or access to an SMTP mail server.

==Getting Moodle==

You have two basic options:
* Download your required version from http://moodle.org/downloads ... OR
* Pull the code from the Git repository (recommended for developers and also makes upgrading very simple):
<pre>
git clone -b MOODLE_34_STABLE git://git.moodle.org/moodle.git
</pre>
...this fetches a complete copy of the Moodle repository and then switches to the {{Version}} Stable branch.

See [[Git_for_Administrators|Git for Administrators ]] for details on using Git to install Moodle code.

Note: Only download Moodle from one of the moodle.org sources. Other versions (e.g. control panel based installers, Linux distribution repositories) cannot be guaranteed to work properly, be upgradable or be supportable.

==Create a database==

* Using your chosen database server, create a new empty database. The default encoding must be UTF8. For example, using MySQL:
<pre>
CREATE DATABASE moodle DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
</pre>
* Create a user/password combination with appropriate permissions for the database. For example (MySQL again):
<pre>
mysql> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,CREATE TEMPORARY TABLES,DROP,INDEX,ALTER ON moodle.* TO 'moodleuser'@'localhost' IDENTIFIED BY 'yourpassword';
</pre>

Notes: It is important to GRANT ON moodle.* as the database name including the '.*' and not just the bare database name. Save this password you use for the Moodle user, since you will need it later in the install.

==Create data directory==

* Create an empty directory to hold Moodle files. It '''must not''' be in the area served by the web server and must have permissions so that the web server user can write to it. Other than that it can be located anywhere. Typically, either make it owned by the web server user or give it write permissions for 'everyone'. If it is on a shared/NFS drive then read [[Caching]] - Moodle caches to this disk area by default and a slow share will mean terrible performance.

==Install Moodle code==

* If you downloaded the zip or tgz file earlier, then unzip / untar / move / copy the Moodle code (obtained above) so that it will be served by your web server (e.g. on Debian based Linux, move to /var/www/html/moodle)
* Check the permissions and make sure that the web server does '''not''' have permissions to write to any of the files in the Moodle code directories (a very common root cause of sites being hacked).
* If you need to, configure your web server to serve the Moodle site with your chosen URL.

==Configure Moodle==

* In the Moodle code directory, find the file ''config-dist.php'' and copy it to a new file called ''config.php'' (but read next step, 'Install Moodle', first).
* Edit config.php with your favourite editor and change the appropriate settings to point to your site, directories and database. ''Note: the Moodle install script will create config.php for you if it does not exist but make sure you (re-)set permissions appropriately afterwards''

==Install Moodle==

* Go to the URL for your moodle site in a browser (installation will complete automatically) or run the command line version at (requires cli version of PHP):
<pre>
/usr/bin/php /path/to/moodle/admin/cli/install.php
</pre>
The CLI creates the config.php for you and will not run if you created one in the previous step.
* After completing the install make sure your file permissions are ok for the Moodle program files (not writeable by web server) and the Moodle data files (writeable by web server).

==Set up cron==

You will need a cron job to run periodically. It is recommended that ''the cron is run every minute'', as required for asynchronous activity deletion when using the [[Recycle bin|recycle bin]]. A typical Unix cron entry will be as follows:
<pre>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php >/dev/null
</pre>
Your site '''will not work properly''' unless cron is running regularly. It is very important you do not skip this step.

See [[Cron]] for details.

==Congratulations!==

You are now ready to use your Moodle site.

If you run into problems, check the [[Installation FAQ]] and visit the [http://moodle.org/mod/forum/view.php?id=28 Installation help forum].

[[Category:Quick guide]]

[[de:Installation in Kürze]]
[[fr:Installation_rapide]]
[[es:Inicio_Rápido_de_Instalación]]

Privacy officer role

2018-07-06T15:06:43Z

Mits: Changed the page name based on en change.

{{Privacy}}
A Privacy officer can respond to data requests and manage the data registry.

==Role set-up==

# Go to 'Define roles' in the Site administration.
# Click the button "Add a new role".
# Set the role archetype to Guest.
# Give the role a name such as 'Privacy officer', short name and description.
# For context types where this role may be assigned, tick system.
# Enter dataprivacy in the filter box, then allow the capabilities tool/dataprivacy:managedataregistry and tool/dataprivacy:managedatarequests, and if necessary tool/dataprivacy:makedatarequestsforchildren.
# Allow more capabilities as follows: moodle/site:configview, moodle/category:viewhiddencategories, moodle/course:viewhiddencourses, moodle/course:view, moodle/course:viewhiddenactivities.
# Click the button "Create this role".

Next

# Go to 'Privacy settings' in the Site administration.
# Click to select the Privacy officer in the Privacy officer role mapping setting.
# Save changes.

==Role assignment==

# Go to 'Assign system roles' in the Site administration.
# Choose the Privacy officer role to assign.
# Select the user in the Potential users list, and use the left-facing arrow button to add them to the Existing users list.

[[Category: Privacy]]
[[Category:Roles]]

[[es:Rol de Oficial de Protección de Datos]]
[[de:Datenschutzbeauftragter-Rolle]]
[[ja:プライバシー責任者ロール]]

Privacy officer role

2018-06-29T14:06:30Z

Mits: ja link

A Privacy officer can respond to data requests and manage the data registry.

==Role set-up==

# Go to 'Define roles' in the Site administration.
# Click the button "Add a new role".
# Set the role archetype to Guest.
# Give the role a name such as 'Privacy officer', short name and description.
# For context types where this role may be assigned, tick system.
# Enter dataprivacy in the filter box, then allow the capabilities tool/dataprivacy:managedataregistry and tool/dataprivacy:managedatarequests, and if necessary tool/dataprivacy:makedatarequestsforchildren.
# Allow more capabilities as follows: moodle/site:configview, moodle/category:viewhiddencategories, moodle/course:viewhiddencourses, moodle/course:view, moodle/course:viewhiddenactivities.
# Click the button "Create this role".

Next

# Go to 'Privacy settings' in the Site administration.
# Click to select the Privacy officer in the Privacy officer role mapping setting.
# Save changes.

==Role assignment==

# Go to 'Assign system roles' in the Site administration.
# Choose the Privacy officer role to assign.
# Select the user in the Potential users list, and use the left-facing arrow button to add them to the Existing users list.

[[Category: Privacy]]
[[Category:Roles]]

[[es:Rol de Oficial de Protección de Datos]]
[[de:Datenschutzbeauftragter-Rolle]]
[[ja:プライバシー管理責任者ロール]]

Adding a new course

2018-06-06T13:23:55Z

Mits: ja link

{{Courses}}
==Adding a course==

By default a regular teacher can't add a new course. To add a new course to Moodle, you need to have either [[Administrator|Administrator]], [[Course creator|Course Creator]] or [[Manager|Manager]] rights.To add a course:
*From the Site administration link, click Courses>Manage courses and categories''

[[File:26addcourse1.png|400px|thumb|center|Click New course in the category page on the right]]

*Click on the category where you want your course to be. For more information see [[Course categories|Course categories]]
*Click the "New course" link
*Enter the [[Course settings|course settings]], and then choose either to "Save and return" to go back to your course, or "Save and display" to go to the next screen.

[[File:newcoursesavereturn.png]]

*On the next screen,if you have chosen "Save and display", choose your students/teachers to assign to the course.

==Deleting a course==

Teachers cannot delete courses. Managers (i.e. users with a role for which the capability [[Capabilities/moodle/course:delete|moodle/course:delete]] is allowed) can delete courses and [[Course creator|course creators]] can delete courses they have created themselves, but only within 24 hours of creating the course. This is so that courses created by mistake may be deleted without needing to ask an administrator.

Administrators can always delete courses.

To delete a course (as an admin or manager):
# From the Site administration link, click Courses > Manage courses and categories
# Click the course's category and click the course in the screen on the right.
# Click the Delete link.

{|
|[[File:26coursedelete.png|200px|thumb|center|Deleting a course]]
|}
You can delete multiple courses by:
*Creating a new (temporary) category. You can name it "To be deleted".
*Select and '''move''' the "About to be deleted" courses to that category ("To be deleted").
*Delete the category ("To be deleted") and choose "Delete ALL - cannot be undone".

There is no user interface for course creators to delete courses they have created; however they can do so by editing the URL of the course from <nowiki>http://yourmoodlesite.net/course/view.php?id=N</nowiki> to <nowiki>http://yourmoodlesite.net/course/delete.php?id=N</nowiki> (replacing 'view' with 'delete').

==Sorting courses==
Courses may be sorted by an admin or manager from ''Administration>Site administration>Courses>Manage courses and categories.''

Courses may be sorted by ascending/descending and by time created.
[[File:coursesort.png|thumb|200px|center|Sorting courses]]

==Course requests==

The course request feature can be enabled by an administrator in ''Administration > Site administration > Courses > Course request''.

An admin can set the default category for course requests, whether users can select a category when requesting a course, and who can receive notification of course requests (from a list of users with the capability [[Capabilities/moodle/site:approvecourse|moodle/site:approvecourse]]).

A 'Request a new course' button will then appear on the 'All courses' page. The All courses page can be accessed via a link in the [[Courses block]].

If course requests are enabled, by default all authenticated users can make course requests. See [[Course requester role]] for details of how to restrict users who can make course requests.

==Bulk course creation==

For full details on how to bulk create courses and use course templates, see [[Upload courses]].

# Go to ''Administration > Site Administration > Courses > Upload courses''.
# Upload a CSV file either by dragging and dropping or using the button to select from the File picker.
# Select your import options and click Preview. If the settings are acceptable, click Upload.

==Course templates==

It is possible, from ''Administration>Site Administration>Courses>Upload courses'' to specify a course and settings to use as template for future courses.

Default blocks for new courses can also be configured in config.php.

===Using an existing course as a template===

First, create or locate on your Moodle the course you wish to use as a template and make a note of its shortname. A template course might for example have common headings or section summaries or policy agreements used throughout the site for consistency.

''Note that only the content of the course will be restored; not its settings. Settings are added separately.''

====Method 1====

*Create your csv file. See [[Upload courses]] for accepted fields.
*From the Site administration link, click Courses>Upload courses and add your file.
*Preview it and scroll down to 'Course process'. In the box 'Restore from this course after upload', add the shortname of your template course.
*If you are creating several courses using the same template and you wish them all to have the same settings, you can specify these in the Default course values.
*Upload your csv file.

{|
|[[File:template1.png|thumb|400px|Adding shortname of template course]]
|
|[[File:26defaultcoursevalues.png|thumb|400|Default course values]]
|}

====Method 2====

*All the settings and the chosen template course can be specified in the csv file you create. Use ''templatecourse'' as the field for your chosen template course, and use the course shortname. See [[Upload courses]] for full list of fields you can include.
*Here is an example of a csv file for restoring a course to be used as a template. It specifies for example the theme, language, enrolment method and alternative names for student and teacher.

<code bash>
shortname,fullname,category,newsitems,theme,lang,format,enrolment_1,enrolment_1_role,role_student,role_teacher,templatecourse
Knit,Knitting,2,0,afterburner,fr,topics,manual,student,NewKnitter,MasterKnitter,OMT
</code>
*Go to Administration>Site administration>Courses>Upload courses and add your csv file.

===Using a backup course as a template===

It is possible during the process of creating courses with a csv file in ''Site administration>Administration>Courses>Upload courses'' to specify and upload a backup file to be used as a template.

*Create your csv file. See [[Upload courses]] for accepted fields.
*From ''Site administration>Administration>Courses>Upload courses'', add your file.
*Preview it and scroll down to 'Course process'. In the box 'Restore from this file after upload', add the backup file you wish to use as the template.
*If you are creating several courses using the same template and you wish them all to have the same settings, you can specify these in the 'Default course values' section.
*Alternatively, you can specify the course settings (such as format, enrolment methods, language) in the csv file. This method is useful if you wish different courses using the same template to have different settings.
*Upload your csv file.
{|
|[[File:template2.png|thumb|400px|Uploading a template course]]
|}

===Using the course templates plugin===
With emeneo's course templates plugin you can very easily create template based courses. More information and the plugin package you can find here: [https://moodle.org/plugins/local_course_templates https://moodle.org/plugins/local_course_templates]

==See also==

===Screencasts===
* [http://youtu.be/MzK2jb-9SwE Bulk course creation]

===Forum discussions===
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=83830 Hide Courses from some users or students] forum discussion

[[de:Kurs anlegen]]
[[es:Añadiendo un nuevo curso]]
[[eu:Ikastaroak_%28Kudeatzaileak%29]]
[[fr:Ajouter_un_cours]]
[[ja:新しいコースを追加する]]

Capabilities/moodle/course:delete

2018-05-21T20:19:37Z

Mits: ja link

{{Capabilities}}
*This allows a user to delete a course within 24 hours of creating it
*This capability is allowed for the default role of manager only

==See also==

* [[Adding a new course]]

[[Category:Capabilities|Course]]
[[Category:Course]]

[[eu:Capabilities/moodle/course:delete]]
[[fr:Capabilities/moodle/course:delete]]
[[es:Capabilities/moodle/course:delete]]
[[ja:ケイパビリティ/moodle/course:delete]]

Capabilities/moodle/course:request

2018-03-09T15:01:55Z

Mits: ja link

{{Capabilities}}
*This capability allows a user to [[Adding a new course|request a course]] (which needs to be approved by a user with the [[Capabilities/moodle/site:approvecourse|capability to approve course requests]]).
*The default [[Authenticated user]] role has this capability set to allow.

==See also==

* [[Course requester role]] for restricting users who can make course requests

[[Category:Capabilities|Course]]
[[Category:Course]]

[[eu:Capabilities/moodle/course:request]]
[[ja:ケイパビリティ/moodle/course:request]]

Course requester role

2018-03-08T15:03:00Z

Mits: ja link

{{Roles}}The role of Course requester may be used to restrict users who can make [[Course request|course requests]], perhaps to teachers only.

==Removing the capability to make course requests==

By default, all authenticated users can make course requests. To change this:

#Access ''Administration > Users > Permissions > Define roles''.
#Edit the authenticated user role and change the capability [[Capabilities/moodle/course:request|moodle/course:request]] from allow to not set.
#Scroll to the bottom (or top) of the page and click the 'Save changes' button.

==Role set-up==

#Access ''Administration > Users > Permissions > Define roles''.
#Click the button "Add a new role"
#Give the role a name e.g. Course requester, short name and description.
#Under "Context types where this role may be assigned", click on the "System" tick box turning it on.
#Change the capability moodle/course:request to allow.
#Click the button "Create this role".

''Note'': It is necessary to create a new role, rather than simply changing the capability for the teacher role, because it needs to be assigned as a system role. (The role of teacher is generally assigned in the course or course category context.)

==Role assignment==

#Access ''Administration > Users > Permissions > Assign system roles''.
#Choose the course requester role to assign.
#Select one or more users in the Potential users list, and use the left-facing arrow button to add it to the Existing users list. If you want all your institution's teachers to be able to make course requests, you need to select and add all their names to the Existing users list.

==Add a Course Request block==

Now, this will work fine for those users who already have a Teacher role in at least ONE course on your Moodle site. When they log in, they will see the list of course(s) that they are enrolled in as Teacher(s) plus an All courses button. Clicking on that '''All courses''' button will show the complete list of courses on the site, plus a '''Request a course''' button, which they will be able to click to request a course.

However, those Moodle site users whom we have assigned to the Course requester role in System ''and who do not yet have a Teacher role in at least ONE course on your Moodle site will not see that '''All courses''' button'', since by default all the available courses will be displayed. And consequently, the '''Request a course''' button will not appear to them. To solve this, a further step is required, viz. creating an HTML block on the front page with a direct link to /course/request.php! And of course that block will have to be made invisible to students etc.

# On the front page add a block: HTML: title: ''Course request'' contents: ''Click here to request a course'' with a link to <yourmoodlesite>/course/request.php
# Click the 'Assign roles' link and then in the administration block click the permissions link and edit the permissions so that only users with a Course requester or Teacher role will be able to view that block; students etc. won't see it.

Now Course requesters who are not yet enrolled as Teachers in Courses will be able to see that HTML block, click on the link and request a course. Of course, this block is redundant for those Course requesters who are also Teachers, but it is needed for Teachers requesting the creation of ''their very first course'' on the Moodle site.

==See also==

* [http://moodle.org/mod/forum/discuss.php?d=195211 Only teachers can request courses - how to do that?] forum discussion

[[es:Rol de solicitante de curso]]
[[ja:コースリクエストロール]]

Course categories

2018-01-14T15:02:46Z

Mits:

{{Courses}}
Course categories organize courses for all Moodle site participants. The default course category on a new Moodle site is "Miscellaneous" (although this can be renamed) A [[Course creator|Course creator]], [[Administrator|Administrator]] or [[Manager|Manager]] can put all courses in the Miscellaneous category. However, teachers and students will find it easier to find their classes if they are organized in descriptive categories.

The list of courses within a category by default shows the teachers and the summary of each course. If the number of courses within a category exceeds 9 (10 or more), then a short list without teachers and summary is shown.

==Adding a category==
Most people organize their courses by department and college or by topic. Be sure to test the organizational scheme with a few users before entering a large number of courses, to save time in moving them later.

Adding categories is very simple:

*Go to ''Administration > Site administration > Courses > Add a category''
*Complete the details required and click 'Create category.'
*Alternatively, you can go to ''Administration>Site administration>Courses>Manage courses and categories'' and click the link 'Create new category'.
*If you are on the category page (or you only have Manager rights at a Course Category level), click the 'Manage courses' button at the top-right of the page and then click the link 'Create new category'.

[[File:Addcategory.png]]

If the category is visible, the course category description will be displayed to users when they enter the category, above the list of courses.

==Editing or moving a category==
*You can edit the details of a course category by clicking the actions icon next to its name in ''Administration>Site administration>Courses>Manage courses and categories.'' and selecting 'Edit'.
*You can move categories up or down by clicking the up/down arrow next to the category you wish to move. You can bulk move categories by checking the box to the left of their name and then by selecting from the dropdown 'Move selected categories to'

[[File:Editmovecategories.png]]

==Adding sub-categories==
*Sometimes it might be useful to have a sub-category of a course. For example, you might have a category "Science" and wish to have sub-categories "Biology", "Chemistry" and "Physics".

*You can make one category a subcategory of another by checking the box to the left of its name and then by selecting from the drop down menu 'Move selected categories to' You can create a new, empty sub-category by clicking the actions icon next to its name in ''Administration>Site administration>Courses>Manage courses and categories.'' and selecting 'Create new subcategory.'

==Hiding categories==
*Categories may be easily hidden or shown via ''Administration>Site administration>Courses>Manage courses and categories'' and clicking the 'eye' icon of the category you wish to hide. Hidden categories are only visible to site administrators or those with the capability to "view hidden courses".

==Sorting categories==
Categories may be sorted by ascending/descending names or ID numbers from ''Administration>Site administration>Courses>Manage courses and categories''

[[File:categorysort.png|thumb|200px|center|Sorting categories]]

Courses within categories may also be sorted. See [[Adding a new course]]

==Setting category depth==

You can limit the number of categories that are displayed in the front page 'List of Categories' or 'Combo List' from ''Administration>Site administration>Front page>Front page settings'' Deeper level categories will appear as links and the user can expand them.

==Assigning users a role in a course category==

To assign a Manager at the Category level, see [[Manager_role#Assigning_the_role_of_Manager_at_the_Category_level | Assign Manager role at category level]].

To enrol teacher or students roles category wide, see [[Category enrolments]].

==See also==
===Screencasts===
[http://youtu.be/1N5Vs_OfVlA Course and category management]]

Using Moodle forum discussions:
* [http://moodle.org/mod/forum/discuss.php?d=47954 Course Summary Sometimes Not Appearing]
* [http://moodle.org/mod/forum/discuss.php?d=102803 Allowing teachers to put courses in categories]

[[fr:Ajouter une catégorie de cours]]
[[es:Categorías de curso]]
[[de:Kursbereiche]]
[[ja:コースカテゴリ]]

Additional name fields

2016-10-27T15:01:57Z

Mits: ja link

{{Accounts}}
As well as first name and surname, the following additional name fields may be used:

* First name - phonetic
* Surname - phonetic
* Middle name
* Alternate name

==Administration settings==

===Full name format===
[[File:participants-after.png|thumb|List of users with full names displayed]]
An administrator can set how names are displayed across the site via the setting 'Full name format' (fullnamedisplay) in ''Administration > Site administration > Users > Permissions > User policies''. The default setting is ''language'', which means that names are displayed according to information from the language pack used on the site. Alternatively, the following placeholders may be used:

* firstname
* lastname
* firstnamephonetic
* lastnamephonetic
* middlename
* alternatename

For example, a user with first name John, surname Doe, middle name James, first name phonetic Jon, and surname phonetic Dough will have his name displayed as

*John James Doe when 'Full name format' is set to ''firstname middlename lastname'' and
*Doe John (Dough Jon) when 'Full name format' is set to ''lastname firstname (lastnamephonetic firstnamephonetic)''

Users with the [[Capabilities/moodle/site:viewfullnames|view full names capability]] (by default users with the role of manager, teacher or non-editing teacher) can always see first and last names, regardless of the "Full name format" setting.

Note for sites upgrading from an earlier version: The 'Full name format' setting was previously in ''Site policies''.

===Alternative full name format===

The alternative full name format setting may be used to define how names are shown to users with the [[Capabilities/moodle/site:viewfullnames|view full names capability]]. For example, it may be set to ''lastname firstname (lastnamephonetic firstnamephonetic)'' so that phonetic names are also displayed.

==User profile settings==

Users can enter additional names by editing their profile in ''Administration > My profile settings > Edit profile''.

First name, surname and any additional names specified by an administrator in 'Full name format' are listed in the General section. Additional names not specified in 'Full name format' are listed in an "Additional names' section.

{|
| [[File:name fields in general section.png|thumb|Name fields as specified in 'Full name format']]
| [[File:additional name fields.png|thumb|Additional name fields]]
|}

[[es:Campos de nombre adicionales]]
[[de:Zusätzliche Namen]]
[[ja:追加氏名フィールド]]

Metacourse examples of use

2016-10-25T15:09:29Z

Mits: ja link

{{Enrolment}}
[[Metacourse]]s can be used in many ways to fill some special needs around student enrolment. Here are some examples scenarios that may help you to understand how they work.

==Yearly intake ==
This example uses LDAP to enrol each year's intake of students onto that year's 'Course Noticeboard'. Then by making each of the Modules meta courses, and assigning their 'child' as that year's 'Course Noticeboard', the learners are automatically enrolled on all of the necessary module

Foundation Degree (2009 intake) [course category]
Course 2009 Noticeboard (uses LDAP to enrol 2009 students)
Year 1 [course category]
:Module 1 (Metacourse linked to 2009 Noticeboard_
:Module 2 (Metacourse linked to 2009 Noticeboard_
:Module 3 (Metacourse linked to 2009 Noticeboard_
:etc.

Foundation Degree (2010 intake) [course category]
Course 2010 Noticeboard (uses LDAP to enrol 2010 students)
Year 1 [course category]
Module 1 (Metacourse linked to 2010 Noticeboard_
Module 2 (Metacourse linked to 2010 Noticeboard_
Module 3 (Metacourse linked to 2010 Noticeboard_

Jerome Di Pietro in [http://moodle.org/mod/forum/discuss.php?d=39438 Teaching Strategies forum]

==1 course that sends its enrolments to 4 other courses ==
Meta courses 1-4 each have created a "child" link to Y which is a normal course. Students enrolling on Course Y are automatically enrolled in Meta courses 1-4.

[[Image:Metacourses2_en.jpg|Upsidedown Meta course Usage|center]]

For example: this would be used, when all five courses are intended to have exactly the same students.

==1 course that gets its enrolment from 4 other courses==
X is a meta course and Courses 1, 2, 3, 4 can be normal courses with standard student enrolments. These courses can contain resources, and activities that are specific to those courses, but they may also only contain enrolments. Students enrolling in Courses 1 or 2, or 3 or 4, are automatically enrolled onto Meta course X when the course is associated as a child course to Meta course X. The meta course is dependent upon its enrolments from each of the non-meta courses, the child courses.

[[Image:Metacourses1_en.jpg|Standard Meta course usage|center]]

For example, a math teacher has 2 algebra and 2 geometry courses and wants a "home room" to place things of interest for all of their students. The teacher creates a meta course called "Teacher's home room" and links the algebra and geometry courses as the "child" courses.

=="Merged course" / 1 course that consolidates enrollment from multiple other courses==
For a course with multiple sections - that is, a course where the same material is taught to students enrolled in several separate sections/courses - it is sometimes desirable to create a "merged course" that is used by students across all sections. This assumes that there is no section-specific information.

To create a "merged course," select one existing course/section that will become the merged metacourse. In that course:

#In the Settings module, navigate to Course administration -> Users -> Enrollment methods.
#Use the Add method drop-down menu to select Course meta link.
#Use the Link course drop-down menu to choose one of the other sections/courses you wish to merge into the metacourse.
#Repeat the preceding steps as necessary for additional sections/courses.

To make it clear which course is the merged metacourse, go to that course and:

#In the Settings module, navigate to Course administration -> Edit settings.
#Change the Course full name appropriately (consider "[Course Number] - [Course Name] - [Course Date]" e.g. "CSSE101 - Introduction to Computer Science - 201210")
#Click Save changes.

To hide the unused sections/courses, go to each course and:

#In the Settings module, navigate to Course administration -> Edit settings.
#Use the Availability drop-down menu to select This course is not available for students.
#Click Save changes.

==Meta course(s) used as libraries==
One or more meta courses are used as a library of resources and activities.

For example, the English department has collected material useful in writing papers, these are set up as meta courses, with links to their regular courses. Teachers can direct or embed a link to a specific reference about citations, or how to select a topic for a paper or suggested reading compiled by students. Thus an English 101 course should be one of the links in the "Writing Papers" meta course. This Meta course holds a resource called "Citations made easy", a Lesson "Select a topic" and a Wiki or database called "Suggested readings from classmates".

==Expanding the library concept==
I teach 4 sections of the same course and use a metacourse as the repository for materials used in the 4 sections. What I did was create the resource in the metacourse and then link that resource to the sections. For instance, I created a web page in the metacourse that included course notes. These course notes are in the form of 17 pdf files. The web page has links to the 17 files that were uploaded to the metacourse. Thus, the files and the web page that students will use to get to the files all exist in the metacourse.

Next I created a link to the web page in my normal courses. To do this I had to execute the web page in the metacourse and copy the address from my browser into the link I created in the normal course.

When the student is in the normal section course, they simply click on the link and the web page in the metacourse appears. The only minor problem is that the student navigation might leave them in the metacourse instead of the normal section course. To lessen this effect, I always launch links to the metacourse in a new window. Normally students understand that they need to close the popup window when they are finished with it.

There are several advantages to using metacourses in this way. First, it saves having to upload the same materials more than once. I can change a file in the metacourse and know that it is changed in all section courses. Second, it saves storage space. Third, it provides the possibility of developing learning objects or mini courses that can be quickly linked to create a new course. Finally, it would allows several teachers to pick and choose what materials to include in their section courses.

One hint, I put all activities (assignments, forums, journals, etc) in the child course, not in the metacourse. This keeps grading segregated and allows me to adjust assignments for a particular section (child).

Harold Kime [http://moodle.org/mod/forum/discuss.php?d=39438 Teaching strategies forum thread].

== Common department area==
Here is how we use metacourses for our district. Lets take a math teacher for example who teaches algebra 1, algebra 2 and geometry. This teacher wants a space (Moodle course) for each of their main subject areas. But they also want a generic space where they can post things for all of the students in all of their classes. This is where a meta course comes into play.

We create a Moodle course for algebra 1, another course for algebra 2 and a 3rd course for geometry. Now we enroll all of the appropriate students into each of these courses. Next we create a meta course and to the meta course we assign the first three courses created. Now by default, all of the students in the first three courses are automatically enrolled in the meta course. Now anything posted in the metacourse is available to all the students in the other three courses.

Randy Orwin [http://moodle.org/mod/forum/discuss.php?d=39438 Teaching strategies forum thread].

==A Diploma course sends its enrolment to meta courses==
A Diploma program involves courses D1, D2, D3, and D4. In this case, you would create a "Diploma" course as a normal course (non-meta course). You would then designate programs D1 through D4 as meta courses and each would show the Diploma course as the "child" course. When a student enrolls in "Diploma", he or she will be automatically enrolled in courses D1 through D4.

==Core subjects with fees based upon course groupings==
You have 3 course subjects and want to offer them for sale in different packages. The meta courses will contain your subjects. A normal (non-Meta course) course will be the gateways to the meta course(s). Course 1 is your gold package. Meta course A, Meta course B and Meta course C all link to Course 1. The silver package is Course 2. Meta courses A and B link to Course 2. You have also set up individual courses that have a link from a specific Meta Course to them. Thus you can offer and charge for each meta course separately or in some combination.

==One course, different student fees==
You have one "Wizbang" course but want to charge a different rate based upon the type of user. The "Wizbang" meta course is the one that holds the content. You create a courses for "Wizbang for Large Corporation users" and "Wizbang for Small Business users". The Wizbang meta course is linked to "Introduction to Wizbang for Large Corporation users" and "Introduction to Wizbang for Small Business users" courses. You can charge a different fee for the non-meta courses, maybe brand or put some unique material in each "Introduction" course but the students will be able to take the same "Wizbang" course.
==Two courses, combined teaching space==
We have automatic enrolment into Moodle using a custom enrolment plugin. We often have two or more courses that are taught together by the same teacher, in the same classroom with the same lectures. We create a metacourse for both courses and add the two individual courses as child courses.
==Student Support Space for degree programme==
We have a programme which is fully online. We have created a metacourse as a support space which includes information for the programme, specific forums for groups of students (using groups & groupings) and Social Forums to allow students to interact with each other.

[[Category:Examples of use]]

[[ja:メタコース使用例]]

Capabilities/moodle/user:viewlastip

2016-08-11T15:05:02Z

Mits: ja link

{{Capabilities}}
*This capability allows a user to view the last IP field in [[User profiles|user profiles]].
*It is set to 'Allow' for the default role of manager only and is not set for other roles.

[[Category:Capabilities|User]]
[[Category:Site administration]]

[[es:Capabilities/moodle/user:viewlastip]]
[[de:Capabilities/moodle/user:viewlastip]]
[[ja:ケイパビリティ/moodle/user:viewlastip]]

View profile

2016-08-10T15:03:39Z

Mits: ja link

{{Accounts}}
*A user may view their own full profile from the user menu top right. They may then personalise the display by clicking the "customise this page" button at the top right of the screen.
*A student or course teacher may see the course profiles of users by clicking their names in ''Navigation>My courses (name of course)>Participants'' Teachers can then access the full profile by clicking the link "full profile" at the bottom of the course profile (if allowed. See 'Viewing full profiles' below).
*An administrator may additionally access and view full profiles via ''Administration>Site administration>Users>Accounts>Browse list of users''.

==Full (site) profile==

Depending on what the user has added to their profile, this gives information such as first and last access, general interests and links to individual course profiles. Users may be messaged from the button at the top of their profile.

A manager or anyone with the capability [[Capabilities/moodle/user:viewlastip]] will also see a link to the IP address from which the user last accessed Moodle.

==Course profile==
A shorter version of users' profiles is available in the course and includes their role(s) and groups in the course and a link to message them. Those with the relevant permissions are also able to access the full profile from here:

==Viewing full profiles==

By default, only admins and managers can view full profiles.

To allow everyone i.e. all authenticated users to view full profiles:

# Go to ''Administration > Site administration > Users > Permissions > Define roles''
# Click the edit icon for authenticated user
# Enter moodle/user:viewdetails in the filter box, then tick the checkbox to allow this capability
# Click the 'Save changes' button

To allow teachers to view full profiles:

# Go to ''Administration > Site administration > Users > Permissions > Define roles'' and click the 'Add a new role' button
# Give the role a name, such as 'Full profile viewer' and tick System as the context type where the role may be assigned
# Copy and paste ''moodle/user:viewdetails'' into the filter box then tick the box to allow the capability
# Click the 'Create this role' button
# Go to ''Administration > Site administration > Users > Permissions > Assign system roles'' and click 'Full profile viewer'
# Assign teachers the role of 'Full profile viewer' by selecting them in the list of potential users on the right and then adding them to the list on the left

==Site administration settings==

An administrator can set the defaults for certain user profile fields from ''Site administration>Users>Accounts>User default preferences''.

These are:
:Email display
:Email format
:Email digest type
:Forum auto-subscribe
:Forum tracking

==See also==
*[[User profiles]]
* [[Edit profile]]
*The capability [[Capabilities/moodle/user:viewdetails|moodle/user:viewdetails]]

[[cs:Profil uživatele]]
[[de:Nutzerprofil ansehen]]
[[eu:Informazio_pertsonala]]
[[fr:Voir le profil]]
[[es:Ver perfil]]
[[ja:ユーザプロファイル]]

Roles and permissions

2016-06-13T15:06:32Z

Mits: Updated ja link

{{Managing a Moodle site}}
A role is a collection of permissions defined for the whole system that you can assign to specific users in specific contexts. The combination of roles and context define a specific user's ability to do something on any page. The most common examples are the roles of student and teacher in the context of a course.

*[[Managing roles]]
*[[Assign roles]]
*[[User policies]]
*[[Using roles]]
*[[Standard roles]]
*[[Creating custom roles]]
*[[Role export and import]]
*[[Permissions]]
*[[Override permissions]]

==See also==

*[[Roles FAQ]]

[[Category:Roles]]

[[es:Roles y permisos]]
[[eu:Rolak]]
[[fr:Rôles et permissions]]
[[ja:ロールおよびパーミッション]]
[[de:Rollen und Rechte]]

Creating custom roles

2016-04-26T15:44:05Z

Mits:

{{Roles}}
==Creating a new role==

To create a custom role:
#Go to ''Administration > Site administration > Users > Permissions > Define roles''.
#Click the "Add a new role" button.
#Select template for the new role or upload a preset
#Give the role a Short name e.g. 'Parent'.The short name is necessary for other plugins in Moodle that may need to refer to the role (e.g. when uploading users from a file or setting enrolments via an enrolment plugin).
#You must provide a full name for all custom roles. If you need to name the role for multiple languages you can use [[Multi language content|multi-lang syntax]] if you wish.
#Give the role a description (optional).
#Select an appropriate role archetype (see below for further information).
#Select the contexts where the role may be assigned e.g. 'User' for Parent role.
#Set permissions as required.
#Scroll to the top or bottom of the page and click the "Create this role" button.

{|
|-
| [[Image:addinganewrole26.png|thumb|Adding a new role and setting context types]]
| [[Image:permissions125.png|thumb|Choose "Allow" where required]]
| [[Image:permissions225.png|thumb|Extra options with "Show advanced" enabled]]
|-
|}

==Role archetypes==

A role archetype

* Is a hard-coded template for a role
* Is used during upgrades when adding defaults for new capabilities - no archetype = no new capabilities during upgrade
* Is used during when resetting a role to determine the defaults - no archetype = reset removes all capabilities

There is no need to set a role archetype for custom roles used for overrides or if the site admin wants to specify new capabilities manually after upgrading.

The archetypes (which relate directly to the built-in roles) are:
* manager
* coursecreator
* editingteacher
* teacher
* guest
* user
* frontpage

==Creating a duplicate role==

To create a duplicate role:
#Go to ''Administration > Site administration > Users > Permissions > Define roles''.
#Click the "Add a new role" button.
#Select existing role as a template
#Give a name and set permissions for your new role; scroll down and click "Create this role".

==New role considerations==

A new role is not automatically listed in course descriptions even if was created by copying a role that is listed, such as Teacher. If you want the new role to appear in the course listing, you must set it explicitly via ''Administration > Site administration > Appearance > Courses>Course Contacts"

==Testing a new role==
''Administration > Switch role to''
Use the "Switch role to" link to see what another role will see in that context.

Since switching roles confines you to those roles you can assign in a course context, this method is only useful for testing course-scoped capabilities (i.e. it will not be useful for testing permissions that apply outside the course context, like moodle/user:edit).

''Tip:'' You can always create test user and assign the new role to them. Then logout as admin and login as the test user. This is really the best way to test a new role.

==Example custom roles==

*[[Parent role|Parent]] - for providing parents/mentors/tutors with permission to view certain information about their children/mentees/tutees
*[[Demo teacher role|Demo teacher]] - for providing a demonstration teacher account with a password which can't be changed
*[[Forum moderator role|Forum moderator]] - for providing a user with permission in a particular forum to edit or delete forum posts, split discussions and move discussions to other forums
*[[Forum poster role]] - a highly restricted custom role which may be given to a visitor account to enable them to post in forums in a guest access course.
*[[Calendar editor role|Calendar editor]] - for enabling a user to add site or course events to the calendar
*[[Blogger role|Blogger]] - for limiting blogging to specific users only
*[[Quiz user with unlimited time role|Quiz user with unlimited time]] - for allowing a user unlimited time to attempt a quiz which has a time limit set
*[[Question creator role|Question creator]] - for enabling students to create questions for use in quizzes
*[[Question sharer]] - for allowing teachers to share questions between courses
*[[Course requester role]] - for restricting users who can make course requests
*[[Feedback template creator]] - for allowing teachers to save as "Public" a Feedback template.
*[[Grading forms publisher]] for allowing teachers to share Advanced grading forms with others
*[[Grading forms manager]] for allowing teachers to share Advanced grading forms with others and to delete templates others have created.
*[[Grade viewer]] for allowing users to view but not edit grades.
*[[Gallery owner role]] - may be used to provide editing capabilities (add and edit gallery images) to users on individual Lightbox Galleries.
*[[Course tagger]] - for allowing users other than managers and editing teachers to tag courses.

==Uploading users to a system role==

Where certain custom roles are applied in the system context, it is possible to upload users to that role in bulk by adding the field ''sysrole1'' (etc) to the CSV file

==See also==

Using Moodle forum discussions:
* [http://moodle.org/mod/forum/discuss.php?d=66782 What happens if a user has multiple roles in a course?]
* [http://moodle.org/mod/forum/discuss.php?d=90140 logged in: what role am I?]
* For more information, Ask questions and get answers on the [http://moodle.org/mod/forum/view.php?id=6826 "Roles and Permissions"] forum.

[[Category:Site administration]]

[[de:Neue Rollen anlegen]]
[[es:Crear roles personalizados]]
[[fr:Création_de_rôles_personnalisés]]
[[ja:カスタムロールの作成]]

Course meta link enrolment

2016-04-16T15:08:07Z

Mits: ja link

{{Enrolment}}
The Course meta link plugin makes it possible for one course, called a metacourse, to bring in enrolments from other courses. The Course meta link plugin needs to be enabled both on the site level by the site admin and has to be enabled within the course.

==Course settings for Course meta link==

*In a course, go to ''Administration > Course administration > Users > Enrolment methods''.
*Click the dropdown menu under the enrolment methods and select 'Course meta link'.
''
[[File:enrolmentmethods29c.png|thumb|center|300px]]
*In the screen that comes up next, select from the dropdown box the course you wish to bring enrolments from and then click 'Add method'.
[[File:newmetalink.png|thumb|center|400px]]

*If several courses need to be added to the course, a button "Add method and create another" allows the teacher or course manager to quickly repeat the process without having to return to the main screen and start again.
*For each linked course, the users may be added to an existing group in the new course, or a new group may be created for them. (Groups from the linked courses are not synced to groups in the new courses. All users will be added to one group when the link is made.)

:Note: ''A teacher in a course will only be able to choose from courses they are teachers in elsewhere.''

*The users from the source (child) course will now be enrolled in the current course - see the numbers in the screenshot below:

[[File:Addedmetacourse.png]]

*When new users are enrolled to the source (child) course, they will be automatically brought into the current target (meta)course.

==Site settings for Course meta link==

The Course meta link plugin may be enabled or disabled throughout the site in ''Administration > Site administration > Plugins > Enrolments > Manage enrol plugins''.

The page ''Administration > Site administration > Plugins > Enrolments > Course meta link'' contains options for defaults that admin can set. (It can be also be accessed by clicking the ''Settings'' link on on the course meta link section of ''Administration > Site administration > Plugins > Enrolments > Manage enrol plugins'')

By default all role assignments from child courses are synchronised to meta courses. However, the "Roles that are not synchronised to metacourses" setting enables administrators to exclude particular roles.

==Course meta link capabilities==

*[[Capabilities/enrol/meta:config|Configure meta enrol instances]]
*[[Capabilities/enrol/meta:selectaslinked|Select course as meta linked]]

==Enabling teachers to add meta links==

An administrator can enable teachers to add course meta links as follows:

* Go to ''Site Administration > Users > Permissions > Define Roles''
* Select the Teacher Role and click on the Edit button
* Scroll down to Course Meta Link as shown in the images below:
{| class="nicetable"
|-
|[[Image:metacoursepermissionset00.png|Permission block for allowing Teachers to link Meta courses.]]
|-
| style="text-align: center;"| The default setting is "Not Set"
|-
|[[Image:metacoursepermissionset01.png|Permission changes for editing.]]
|-
| style="text-align: center;"| When the Edit button is clicked, the panel changes to "Allow" and a checkbox
|-
|[[Image:metacoursepermissionset02.png|Setting permission to allow Teachers to link Meta courses.]]
|-
| style="text-align: center;"| Change to "Allow" by a click on the checkbox.
|}
* Scroll to the bottom of the page to save your changes.

==Examples of meta-linked courses==

{| class="nicetable"
|-
![[Image:simplemetacourse0.png|thumb|left|200px|Created - a child course and a meta course.]]
![[Image:simplemetacourse1.png|thumb|left|200px|Associating one child course and one meta course.]]
|}

Examples: one "child" course (a course linked to a meta course) can be associated with many meta courses. Or one meta course can have many child courses associated with it. Both the child courses (non-meta courses) and the meta courses are independent and can be recycled many times, that is, each can be associated with many of the other.

{| class="nicetable"
|-
![[Image:simplemetacourse2.png|thumb|left|200px|2 child courses and a meta course.]]
![[Image:simplemetacourse3.png|thumb|left|200px|1 child course and 2 meta courses.]]
![[Image:simplemetacourse4a.png|thumb|left|200px|3 child courses and 2 meta courses.]]
|}

There is one limitation: you cannot 'nest' metacourses. In other words, if you have child course A linked to meta course B, and you then link B as a child course to meta course C, a student enrolled in A will be added to B, but not to C. In this situation, you would need to add a meta link directly between A and C instead of trying to nest them. (Another option might be to use [[Cohorts]].)

==See also==

Some known issues:

* MDL-34938 - Important Open Issue: Enrolment expiration date settings in child course do not properly unenrol students from the Meta-course
* MDL-27628 - A workaround in the tracker for adding more than one course at a time

How to use:
* [https://moodle.org/mod/forum/discuss.php?d=316161#p1266891 Re: Help setting up meta link metacourses with parent child courses] forum post
* [http://www.youtube.com/watch?v=hA5QcTb13no&feature=player_embedded Screencast showing how to use the Course meta link plugin to make a Metacourse]
*[[Metacourse examples of use]]

[[de:Meta-Einschreibung]]
[[es:Enlace a metacurso]]
[[ja:コースメタリンク]]

Managing repositories

2016-04-10T14:02:33Z

Mits: ja link

{{Repositories}}
==Enabling repositories==

Repositories can be enabled by an administrator in ''Site administration > Plugins > Repositories > Manage repositories''.

A repository plugin may be set to one of three possible statuses:

* "Enabled and visible" means available for use in the [[File picker]]
* "Enabled and hidden" means not available in the [[File picker]]
* "Disabled" means not available for use and if content has been added to your site you will be given the following message:
<pre>
Are you sure you want to remove this repository plugin, its options and all of its instances - [Repository Name here]? If you choose "Continue and download", file references to external contents will be downloaded to Moodle. This could take a long time to process.
</pre>
With options to Continue, Continue and download, or Cancel.

The order in which repositories are shown in the [[File picker|file picker]] may be set using the up and down arrows.

==Vocabulary==
'''Repository plugin''': it is also called a repository type. It can be named Box, Flickr, Mahara, Youtube... Adding a plugin allow users to create instances of this plugin. Only instances are displayed into the file picker. Type only exist in order to let a Moodle administrator to deactivate/delete all instances of a type in one click.

'''Repository instance''': An instance is displayed into the file picker and it is the access point to an external repository. An instance can have specific settings (for example be linked to a personal account).

*First case: when you add the plugin, an instance is automatically created and can not be edited. The Moodle administrator cannot change the instance name. The instance name displayed into the file picker will be exactly the same as the plugin name. For example Youtube, Box...
*Second case: the plugin allow the Moodle administrator to add multiple instances. An instance has a name for example Flickr Public access to Martin account, Martin's Mahara... For this second case it is important to identify two different kind of instances:
#Common instances: The instances set by Moodle administrator in these same administration pages will be available into any file picker.
#Private instance: A teacher can set some instances available only for a course, and an user can set some instances only available for himself. In order to set instances for a course the teacher will go to the course page, and in order to set instances for a personal use, a user will go on his profile page. An administrator cannot add/edit private instances from the administration pages.

==Common repository settings==

Common repository settings can be set by an administrator in ''Site administration > Plugins > Repositories > Common Repository settings'':

===Cache expire===
You can specify how long in seconds file listings are cached locally when browsing external repositories.

===Timeout settings===

If users are reporting timeouts when using repositories, an admin can increase the timeout for downloading or synchronising files.

====Get file timeout====
Timeout in seconds for downloading an external file into Moodle. Defaults to 30.
====Sync file timeout====
Timeout in seconds for syncronising the external file size. Defaults to 1.
====Sync image timeout====
Timeout in seconds for downloading an image file from external repository during syncronisation. Defaults to 3.

===Allow external links===

With some repositories such as Flickr and Wikimedia, users can have the choice whether to copy the media into Moodle (the preferred solution) or to make a link to it instead.

Defaults to Yes.

===Legacy course files in new courses===

This repository is not normally available in new courses as it is designed for upgraded 1.9 courses. However, if it is checked here then it will appear when new courses are created - but certain backup and restore features won't work with it.

See [[Legacy course files]] for more details. This should not be enabled in sites not originally upgraded from Moodle 1.9.

Defaults to No.

===Allow adding to legacy course files===

When 'Legacy course files' is available in a course, this setting controls if users are able to add new files to it. When enabled, users will be able to add files and directories, as well as delete. When disabled, users will not be able to add files and directories.

==Repository capabilities==

Authenticated user role:

*[[Capabilities/repository/alfresco:view|View Alfresco repository]]
*[[Capabilities/repository/areafiles:view|View Embedded files]]
*[[Capabilities/repository/boxnet:view|View Box repository]]
*[[Capabilities/repository/dropbox:view|View a Dropbox folder]]
*[[Capabilities/repository/flickr:view|View Flickr repository]]
*[[Capabilities/repository/flickr public:view|Use Flickr public repository in file picker]]
*[[Capabilities/repository/googledocs:view|View Google Drive repository]]
*[[Capabilities/repository/merlot:view|View the Merlot repository]]
*[[Capabilities/repository/picasa:view|View Picasa repository]]
*[[Capabilities/repository/recent:view|View Recent files]]
*[[Capabilities/repository/s3:view|View Amazon s3 repository]]
*[[Capabilities/repository/skydrive:view|View Microsoft OneDrive repository]]
*[[Capabilities/repository/upload:view|Use uploading in file picker]]
*[[Capabilities/repository/url:view|Use URL downloader in file picker]]
*[[Capabilities/repository/user:view|View use Private files]]
*[[Capabilities/repository/wikimedia:view|View Wikimedia repository]]
*[[Capabilities/repository/youtube:view|Use YouTube in file picker]]

Manager, Course creator, Teacher, Non-editing teacher Roles:

*[[Capabilities/repository/coursefiles:view|Use Legacy course files repository]]
*[[Capabilities/repository/filesystem:view|View File system repository]]
*[[Capabilities/repository/local:view|View Server repository]]
*[[Capabilities/repository/webdav:view|View WebDav repository]]

[[de:Repositories verwalten]]
[[es:Gestionando repositorios]]
[[ja:リポジトリ管理]]

Repositories FAQ

2016-01-30T15:38:39Z

Mits: ja link

{{Repositories}}
==What is a repository?==
A repository can be thought of as a storage area from which users can retrieve files to add to their course. There are several repositories enabled by default, such as [[Server files]] which contains files from other courses a user has access to, or [[Upload a file repository| Upload a file]] which allows the user to search their computer or USB drive for a file to upload. Other repositories include [[Google Docs repository|Google Drive]],or [[Flickr repository|Flickr]]. See [[Repositories]] for more information.

==How can I enable repositories in Moodle?==

Repositories can be enabled by a site administrator in ''Administration > Site administration > Plugins > Repositories > Manage repositories''.

All enabled and visible repositories will appear in the file picker.

==How can I delete an embedded file previously added using the file picker?==

There is no need to do anything, as any unused files are detected and then deleted automatically after a period of time. Users cannot delete files manually, since they may be used elsewhere.

When an activity or resource which uses a file is deleted, the file is moved immediately to trash. The frequency with which trash is emptied i.e. files are deleted depends on the settings in ''Site administration > Server > Scheduled tasks'' (\core\task\file_trash_cleanup_task)

See also the forum thread [https://moodle.org/mod/forum/discuss.php?d=317135#p1271171 Deleting uploaded files].

==If I add a file (File resources) to a page, then delete the File resource, will the file I added remain in my Recent files list?==

No. The file will not be available.

==How do I create a new repository on my site?==
You can create a new repository that will show up on the file picker. See [[File system repository]].

==How can I prevent students from accessing the private files repository?==
If you want to prevent students from accessing it but still wish other users to access it, follow these steps:
#In ''Administration>Site administration>Users>Permissions>Define Roles'' create a new role (such as "no private files") and assign it in the system context. (See [[Creating custom roles]] for help creating a new role)
#Search for and set the capabilities ''moodle/user:manageownfiles'' and ''repository/user:view'' to '''prohibit.'''
#In ''Administration>Site administration>Users>Permissions>Assign system roles'', give this role to the student(s) you do not wish to access private files.
#They may be enrolled as normal students in courses, but will not be able to use their private files.

An alternative, but more dramatic, because it involves modifying standard roles, is to edit both the authenticated user role AND the student role to prevent the capabilities "moodle/user:manageownfiles" and "repository/user:view" - and then edit the teacher role (and any others) to allow them. You have to do it to the authenticated user role as well, as all users are authenticated users in the system as well as teachers or students.

==What happens if a teacher adds a file from their Private files to the course and they later leave and their account is closed?==
As long as a file is used in a context, such as a course, the file should remains available in that context.

That holds true when a teacher copies a file in a course from his My private files area and also when a teacher creates an alias/shortcut: in the latter case if a teacher deletes his files from My private files area that are used as alias/shortcut in some courses, Moodle will convert existing alias/shortcuts into file copies, so your course file links won't break. ''(copied from [https://moodle.org/mod/forum/discuss.php?d=2287 forum thread thanks to Andrea Bicciolo]''

==I cannot access a student's repositories when logged in as that student==
This is intentional, as there is a security and privacy risk involved in an administrator being able to log in as a student and then explore and use the student's Google Drive, Dropbox and other similar repositories.

==See also==

* [[File picker FAQ]]
* [[File system repository FAQ]]
* Using Moodle [http://moodle.org/mod/forum/view.php?id=1807 Repositories forum]

[[Category:FAQ]]

[[de:Repositories FAQ]]
[[es:Repositorios FAQ]]
[[ja:リポジトリFAQ]]

Repositories

2015-12-08T15:03:08Z

Mits:

{{Managing content}}
Repositories in Moodle enable users to add files to a course and other locations in Moodle. Repositories provide access to specific types of file sources. They can also allow, where appropriate, users to upload files, access previously uploaded files, and to easily bring content into Moodle from external sources, such as Flickr or Google Docs.

See [[Managing repositories]] for more on configuring and managing them.

==Standard repositories==

Repositories are managed in ''Site administration > Plugins > Repositories > Manage repositories''. Standard repositories come with default Moodle. It is also possible to add additional repositories via Moodle plugins.

===Repositories enabled by default===

* [[Embedded files repository|Embedded files]] - Allows linking to files and images available to the user that have been added/embedded in their course activities
* [[Server files repository|Server files]] - Gives access to files elsewhere on the Moodle site (limited by a user's permissions)
* [[Recent files repository|Recent files]] - Shows the last 50 files you have uploaded, according to the context
* [[Upload a file repository|Upload a file]] - Enables the "Upload a file" option in the site File picker to allow users to browse for and upload files
* [[Private files]] - Enables access to a personal storage area for every user
* [[URL downloader repository|URL downloader]] - Allows downloading of files and images from a particular URL
* [[Wikimedia repository|Wikimedia]] - Let's users search for and insert media (images) from Wikipedia

===Additional standard repositories disabled by default===
These may be enabled and set to visible or hidden by a site administrator.

* [[Alfresco repository|Alfresco]] - link to or copy files from Alfresco into Moodle
* [[Box repository|Box]] - bring files in from your Box account
* [[Legacy course files]] - use the old system from 1.9 of "course files" (pertains to sites upgraded to 1.9)
* [[Dropbox repository|Dropbox]] - link to or copy files from Dropbox
* [[EQUELLA repository|EQUELLA]] - link to files in an EQUELLA installation
* [[File_system_repository|File system]] - access files uploaded to a folder on your server (by, eg FTP)
* [[Flickr repository|Flickr]] - search for and display images from your personal Flickr account
* [[Flickr public repository|Flickr public]] - search for and display images publicly available from Flickr
* [[Google Drive repository|Google Drive]] - bring files from your Google Drive account
* [[Merlot.org repository|Merlot.org]] - bring resources in from Merlot.org
* [[Picasa web album repository|Picasa web album]] - search for and display images from your Picasa account
* [[Amazon S3 repository|Amazon S3]] - enables users to copy files from Amazon S3 storage instances
* [[Skydrive repository|OneDrive]] bring in files from your Microsoft OneDrive
* [[WebDAV repository|WebDAV]] -bring in files from external sources using WebDAV protocol
* [[Youtube videos repository|Youtube videos]] - search for and display Youtube videos

==See also==

* [[Managing repositories]]
* [[Repositories FAQ]]
* [http://www.youtube.com/watch?v=zdrdyev82bU Repositories in Moodle 2.0 video]
* [http://www.somerandomthoughts.com/blog/whitepaper-moodle-2-repositories/ Whitepaper – Moodle 2 Repositories] by Gavin Henrick
* [http://www.moodlerooms.com/resources/blog/five-tips-using-new-file-repository-system-moodle Five Tips for Using the New File Repository System in Moodle] by Marcelo Mendes
* [[:dev:Repository plugins]] developer documentation
* [http://moodle.org/plugins/browse.php?list=category&id=25 Moodle Repository Plugins database]
* [http://moodle.org/mod/forum/view.php?id=1807 Moodle Repositories discussion forum]

[[Category:Repositories]]

[[es:Repositorios]]
[[eu:Biltegiak]]
[[de:Repositories]]
[[fr:Dépôts]]
[[ja:リポジトリ]]

Unenrolment

2015-11-30T04:22:21Z

Mits: ja link

{{Course enrolment}}
Unenrolment is the process of removing users from a course. It is controlled by one or more of the following:

* The enrolment duration, which suspends students after the specified time has elapsed. Some plugins include the option to unenrol users after enrolment expiration
* For self enrolment, the 'Unenrol inactive after' setting in ''Administration > Course administration > Users > Enrolment methods > Self enrolment'' can be set to specify a time after which a student is automatically unenrolled from a course if they haven't accessed it in that time
* An [[Enrolment plugins|enrolment plugin]] may decide that the enrolment has expired, for example, if a user for a course is not present in an LDAP database, or if a Flat file is processed by Cron.

In addition, users with the appropriate permission can unenrol themself from a course.

==Enrolment duration==

The default enrolment duration for manual enrolment can be set in ''Administration > Course administration > Users > Enrolment methods > Manual enrolment''. It can be amended from the default value when enrolling users manually in ''Administration > Course administration > Users > Enrolled users''.

The enrolment duration for self enrolment can be set in ''Administration > Course administration > Users > Enrolment methods > Self enrolment''.

==Bulk unenrolment==

Users who were previously manually enrolled may be unenrolled in bulk via ''Administration > Course administraton > Users > Enrolment methods'' then clicking on the 'Enrol' users icon.

==Unenrolment and grade history==

When a user is unenrolled, their grade history is not deleted. If a user is unenrolled accidentally, their grades can be restored by going to ''Administration > Course administration > Users > Enrolled users'', clicking 'Enrol users' and making sure that the 'Recover user's old grades if possible' checkbox is ticked in the enrolment options before re-enrolling the user.

Users enrolled with methods other than manual will have their grades restored depending on the value of "recovergradesdefault" in ''Administration > Site administration > Grades > General settings''.

==Suspended or Unenrolled?==

'''Suspended users''' are not longer able to access any of their courses on Moodle but their data is preserved, so it is possible for them to return to their course at a later time. This might be useful for example, for keeping safe the work of students who have left the establishment but whose data might be needed for inspection in future years. Suspended users currently still appear in the gradebook but a teacher can select in their Grader report preferences to show only active users or all users (including suspended users). See [[Grade settings]] for more details.

''Note:'' A single user may be suspended by an admin user or manager by editing the user's profile and selecting "Suspended account". Groups of users may be suspended from "Users > Enrolled users". With the manual enrolments selected, choose "Edit user enrolments" and "Alter status > Suspended"''.

It is also possible to suspend users from courses via csv/text file from ''Site administration > Users > Accounts > Upload users'' using the enrolstatus field, where 1 against a user means they are suspended (and leaving blank means they are still enrolled.)

'''Unenrolled users''' do not normally retain any data and will not appear in the gradebook. However, see [[#Unenrolment and grade history]] Unenrolment is typically more final than suspension.

==See also==
[http://www.screencast.com/t/XtPhA6w2SM Screencast: how to bulk unenrol students from a course.]

[[Category:Site administration]]

[[eu:Desmatrikulatzea]]
[[fr:Désinscription]]
[[de:Abmelden aus einem Kurs]]
[[es:Des-inscripción]]
[[ja:登録解除]]

Import course data

2015-09-01T15:02:59Z

Mits: ja link

{{Reusing activities}}
Course activities and resources may be imported from any other course that the teacher has editing permissions in. This will allow teachers to re-use instead of re-creating one or more [[Activities|activities]] or [[Resources|resources]].

Import course data is similar to a backup and restore process and does not include any user data.

==How to import activities or resources==

*In ''Administration > Course Administration'', click on the ''Import'' link:

[[File:Importactivities.png]]

*Select the course you wish to import from and click ''Continue''.
*You will be presented with the "backup settings" page. Use the check boxes for import activities, blocks and or filters as types of items which will show on the next screen.

[[File:Importsettings.png]]

*Select the elements you want to include in the import in the Schema settings step.

[[File:Includeforimport.png]]

*Review and click ''Perform import'' or click the cancel or previous buttons. The confirmation page will place green check marks and red marks next to the backup settings and include item list for you to review.

[[File:Includeforimportconfirm.png]]

*You should see the "Import complete. Click continue to return to the course." message, or an error message indicating that the import process did not take place.

==Examples and tips==

*Importing a quiz from course A to course B, will also add the questions to the question bank so you can use them in new quizzes.
*''Tip:'' Groups can also be imported as a batch from a file.
* ''Tip:'' It may be necessary to check all Activities (Forums, Assignments, etc.) to assure they are now using HTML format. Due to the change in the HTML editor from 1.9 to 2.2, editing of Activities comes up as "Moodle Auto-format" which displays the HTML version of the Description. Once the "Moodle Auto-format" has been changed to "HTML format" the new HTML editor is available by default when editing.

==Import course capabilities==

* [[Capabilities/moodle/backup:backuptargetimport|Backup for import]] - allows a user to backup a course ready for importing into another course
* [[Capabilities/moodle/restore:restoretargetimport|Restore from files targeted as import]] - allows a user to import activities or resources from another course

==See also==
*[[Course backup]] & [[Course restore]] - for a similar process

[[fr:Importation]]
[[de:Kursdaten importieren]]
[[es:Importar datos de curso]]
[[ja:コースデータをインポートする]]

Capabilities/moodle/restore:restoretargetimport

2015-08-31T15:03:18Z

Mits: ja link

{{Capabilities}}
*This allows a user to [[Import course data|import activities or resources from another course]]
*Together with the capability [[Capabilities/moodle/backup:backuptargetimport|moodle/backup:backuptargetimport]], this allows a user to duplicate an activity or resource using the x2 icon on the course page (when editing is turned on)
*This capability is allowed for the default roles of manager and teacher

==See also==

* [[Reusing activities]]

[[Category:Capabilities|Backup]]
[[Category:Backup]]

[[es:Capabilities/moodle/restore:restoretargetimport]]
[[ja:ケイパビリティ/moodle/restore:restoretargetimport]]

Capabilities/moodle/backup:backuptargetimport

2015-08-24T15:32:35Z

Mits: ja link

{{Capabilities}}
*This allows a user to backup a course ready for importing into another course
*Together with the capability [[Capabilities/moodle/restore:restoretargetimport|moodle/restore:restoretargetimport]], this allows a user to duplicate an activity or resource using the x2 icon on the course page (when editing is turned on)
*This capability is allowed for the default roles of manager and teacher

==See also==

* [[Reusing activities]]
* [[Import course data]]

[[Category:Capabilities|Backup]]
[[Category:Backup]]

[[ja:ケイパビリティ/moodle/backup:backuptargetimport]]

SSL certificate for moodle.org

2015-06-08T15:25:35Z

Mits: ja link

{{Security}}
== Synopsis ==

'''NOTE: This has been updated as of 04/11/2013 - Moodle has moved to the GeoTrust Certificate Authority'''

When you, as an administrator, [[Notifications|check for available updates]] or [[Automatic updates deployment|install an update]], your Moodle site needs to communicate with moodle.org. This communication is done via the secure HTTPS protocol. Your Moodle site validates the SSL certificate of moodle.org (such as the [https://moodle.org/plugins Moodle plugins directory]) and verifies its identity. To pass this verification, there must be a certificate (in the PEM format) of the [http://en.wikipedia.org/wiki/Certificate_authority certificate authority (CA)] that issued the certificate for moodle.org installed on your server.

The SSL certificate for moodle.org has been issued by the [http://www.geotrust.com/resources/root-certificates/ GeoTrust Certificate Authority].

== Problem ==

If this CA certificate is missing, the remote site (moodle.org) can not be verified and so your Moodle site will refuse to fetch the data (to protect you against so called man-in-the-middle attack). The exact location of the certificate on your server depends on the OS type and other settings. On Linux servers it may be typically found at ''/usr/share/ca-certificates/mozilla/GeoTrust_Primary_Certification_Authority.crt'' for example.

A missing CA certificate results in an error when checking for available updates and attempting to install them.

== Solutions ==

=== Update your operating system (recommended) ===

The recommended way to fix this problem is to update your server's operating system so that it contains recent SSL certificates from common certificate authorities. This does not seem to help for Windows servers though. At Windows, the cURL library bundled with PHP does not use the CA certificates installed in the OS and you will have to use the alternative solution described below.

For Debian and RedHat based distributions, CA certificates are distributed in the ''ca-certificates'' package. Gentoo servers provide them via the ''app-misc/ca-certificates'' ebuild. It's also a good idea to make sure that the OpenSSL libraries (libssl) and cURL libraries (libcurl) are up-to-date on your server.

=== Provide the CA certificate manually ===

If updating the operating system is not an option for you, or the administrator of the server refuses to update the CA certificates on the server (despite there being no good reason for not doing so), or updating the CA installed in the OS did not help (such as in case of Windows servers), a possible workaround is to download the bundle of required certificates from the [http://curl.haxx.se/ca/ cURL] site. You need to download the file [http://curl.haxx.se/ca/cacert.pem cacert.pem] from there and put it into your ''moodledata/moodleorgca.crt'' file (i.e. download the cacert.pem file, rename it to moodleorgca.crt and upload it into your mooodledata). If this file is found in moodledata, Moodle will use it instead of relying on certificates provided by the operating system.

It must be highlighted that having the CA certificate on your server's operating system as described above is really the recommended solution. The solution based on moodleorgca.crt should only be considered as a temporary fix (although it seems to be the only way to make it work at Windows servers).

Alternatively, the direct root certificate can be found here, which you may download and install on your system.
[http://www.geotrust.com/resources/root_certificates/certificates/GeoTrust_Primary_CA.pem GeoTrust Primary CA]

[[es:SSL certificate for moodle.org]]
[[ja:moodle.orgのSSL証明書]]

History

2015-04-09T17:47:01Z

Mits: ja link

{{About Moodle}}
Growing up in the Australian outback in the late 1970s, Moodle's Founder and Lead Developer Martin Dougiamas took lessons from the School of the Air, giving him from a young age an insight into distance learning.

As an adult, he worked and later studied at Curtin University, where his experience with WebCT prompted him to investigate an alternative method of online teaching. In 1999 he started trialling early prototypes of a new LMS, the experiences of which formed the basis for his paper [https://otl.curtin.edu.au/professional_development/conferences/tlf/tlf2000/dougiamas.html Improving the Effectiveness of online Learning]. He registered the word 'Moodle' as a [https://docs.moodle.org/dev/License trademark of Moodle Pty Ltd] and explained his choice of name in a [https://moodle.org/mod/forum/discuss.php?d=27533&parent=129848 forum post] some years later.

Research continued: the first ever Moodle site was Peter Taylor's http://smec2001.moodle.com/ at Curtin University , with Martin making the [https://moodle.org/mod/forum/discuss.php?d=1 first post] on his own Moodle.com site in November 2001. The pair published [http://dougiamas.com/writing/herdsa2002/ An Interpretive analysis of an internet based course constructed using a new courseware tool called Moodle.]

By the end of 2001, Moodle could be downloaded via CVS (Git arrived in 2010 and replaced CVS in 2013) and basic installation documentation was available. It was still very much one man's vision, with Martin setting up the [https://tracker.moodle.org/secure/Dashboard.jspa tracker in May 2002] "so you can see what I am working on."

[https://moodle.org/mod/forum/discuss.php?d=31 Moodle 1.0] was released in August 2002. Users were discussing Moodle on a new forum, translating Moodle into different languages and creating themes. A year later, the first contributed module (workshop) was released and [https://moodle.org/ Moodle.org] became the community arm of Moodle, with [https://moodle.com Moodle.com] representing the commercial aspect.

Moodle grew quickly: the first ever Moodle Moot was held in Oxford in 2004 and companies started applying to become [http://moodle.com/partners/ Moodle partners.] 2005 marked the move to [https://moodle.org/mod/forum/discuss.php?d=32727 dedicated premises] with Martin and 4 others; [http://moodle.com/contact/ the current HQ] at Richardson St West Perth, houses 16 with 11 working remotely. At the Spanish Moodle Moot 2005 in Las Palmas de Gran Canaria, the mojito established itself as the unofficial - and then subsequently official - Moodle Moot drink. (See blog post: [http://www.moodleblog.net/2014/03/07/the-history-of-moodle-mojitos/ Moodle Mojitos History])

With improved documentation and new certification , Moodle had established itself by 2007 as a leading and [https://moodle.org/mod/forum/discuss.php?d=68408 award-winning open source LMS]. From 1000 registered sites in 2004, it had gone to half a million users in 2008 and over a million users in 2010, with over 50 Moodle partners. Its translation repository [[:dev:AMOS_manual|AMOS]] held over 100 languages. The long awaited [https://moodle.org/mod/forum/discuss.php?d=162906 Moodle 2.0] came out in November 2010 and now, regular releases bring enhanced features every six months. The current focus is on mobile technology: an [https://moodle.org/mod/forum/discuss.php?d=227988 official HTML5 app] was released in 2013 and the latest version of Moodle includes a customisable theme suitable for all screen sizes.

The inauguration of the [http://research.moodle.net/ Moodle Research conference] in 2012 served as a reminder that, however advanced the technology, Moodle design and development is guided by [[Philosophy| social constructionist pedagogy]]. During September 2013, the official Moodle MOOC, [http://learn.moodle.net Learn Moodle], introduced over 9000 participants to Moodle's basic features. Educators everywhere are encouraged to share their experiences, just as did Martin over a decade previously. The MOOC was repeated in January 2015 and will be run on a regular, six monthly basis.

[[es:Historia]]
[[de:Historie]]
[[ja:歴史]]

Amazon EC2 Cloud Services Installation

2015-01-02T15:48:47Z

Mits: ja link

This is essentially a linux box in the cloud but at the time of writing I did not like to add it to the Linux category, it seems more general than that somehow. If this install lacks detail or doesn't work then see comments attached to this page. I start this off with some assumptions and then go though a full install using the cli.
The assumptions are that you have an Amazon 32 bit EC2 Linux server setup and you have ssh & http access to it.

= Install all the requirements =
From the cli as root or sudo

yum install httpd
yum install mysql-server
yum install git
yum install php
yum install php-gd
yum install php-pear
yum install php-mbstring
yum install memcached
yum install php-mcrypt
yum install php-xmlrpc
yum install php-soap
yum install php-intl
yum install php-zip
yum install php-zts
yum install php-xml

Or save some typing and copy and paste this into the terminal. It will install everything one should need for a Moodle installation:

sudo yum -y install aspell aspell-en aspell-fr aspell-es cvs git httpd memcached mysql mysql-server php php-cli php-gd php-intl php-mbstring php-mcrypt php-mysql php-pdo php-pear php-pecl-zip php-pspell php-soap php-xml php-xmlrpc php-zip php-zts unzip zip zip.so

= To ensure that mysql and httpd come up on boot. =

chkconfig mysqld on
chkconfig httpd on

= To ensure that utf8 is used by mysql =

edit /etc/my.cnf to read as follows (I have found that the precise lines required seem to vary as time goes on)
Back up my.cnf first with
cp /etc/my.cnf /etc/mycnf.original

Then edit to read

[mysqld]
default-character-set=utf8
default-collation=utf8_unicode_ci
character-set-server=utf8
collation-server=utf8_unicode_ci
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
[client]
default-character-set=utf8

Check that mysql restarts with
service mysqld restart

NB edit. Later with FC16 I found that I needed to make my.cnf read

[mysqld]
# Settings user and group are ignored when systemd is used.
# If you need to run mysqld under different user or group,
# customize your systemd unit file for mysqld according to the
# instructions in http://fedoraproject.org/wiki/Systemd
character-set-server=utf8
collation-server=utf8_unicode_ci
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

= In order to make sure php is included when httpd comes up =

make sure you have a file called /etc/httpd/conf.d/php.conf whose contents are like the following

<IfModule prefork.c>
LoadModule php5_module modules/libphp5.so
</IfModule> <IfModule worker.c>
LoadModule php5_module modules/libphp5-zts.so
</IfModule>
AddHandler php5-script .php AddType text/html .php
DirectoryIndex index.php

At the time of writing 26-01-2012) (php-common should provide zip.so but it doesn't so I have put a copy here (http://moodle.org/mod/forum/discuss.php?d=194589))
Attached to a forum post. Perhaps a wiki buff could fix that better.

Once you have got zip.so, put it in /usr/lib/php/modules

Also you need to add

extension=zip.so

to your php.ini (in /etc)

= Create the database, database user and access rights =
run

mysql_secure_installation

Answer all the questions conservatively. (e.g. You will not need test databases or for root to have any other mysql access than local.) This will create a root mysql pw for you. Mysql users are nothing whatsoever to do with you unix users.

run
mysql -u root -p
<password you set above>

In mysql you need to

1. make a database. The name can be anything you like. I used moodledb

2. make a database user. The name can be anything you like. I used moodledbuser.

3. give that user rights to access the database from the localhost.

4. No db access is required by anyone from any other host than the localhost

** Now you are in mysql and all the commands are mysql commands and could equally be run on a windows instance of mysql. Do not forget the ";" after each command.

create database moodledb;
grant all privileges on moodledb.* to moodledbuser@localhost identified by '<put a pw here>';
quit

TEST the above by doing

mysql -u moodledbuser -p
<password>

If you get connected OK then you can go on and quit.

= Create moodledata folder =
mkdir /var/www/moodledata

The default root folder for apache is /var/www/html and so moodledata is not accessible from the web.
Next, give the apache user all the access rights to moodledata. This is better than chmod 777 which some users seem to do.

chown apache:apache /var/www/moodledata

= Fetch moodle =

cd /var/www/html
git clone git://git.moodle.org/moodle.git

This should put all of moodle in a directory called moodle in the correct folder /var/www/html. It takes a while but you get %age feedback.

There are more sophisticated git commands, see git docs in moodle docs for more info.
Also, you may give the apache user ownership of the site, this way, when you install, the script will be able to create the config.php file.
If you leave the owner as root, you will have to paste the suggested config.php into /var/www/html/moodle

To give apache ownership do

chown -R apache:apache /var/www/html/moodle

= Do the install =

Visit http://<your amazon host>/moodle

Well, it worked for me!

= Other Resources =

For another method of using Amazon EC2 for Moodle hosting you can utilize the free image created by Bitnami.org: http://bitnami.org/stack/moodle which makes creating a Moodle server on Amazon a snap (no command line necessary)

[[ja:Amazon EC2クラウドサービスインストレーション]]

Badges settings

2014-06-19T15:16:21Z

Mits:

{{Badges}}

==Individual user settings==
*A user can [[Managing badges|manage badges]] from ''Navigation>My profile>My badges''.
*A user can view available course badges from ''Navigation>Current course>Badges''.

{|
|[[File:coursebadgenav1.png|thumb|Viewing course badges]]
|}

==Viewing the badges of other users==

{{New features}}

*A student can view other students' course badges by going to ''Navigation>Participants'' and clicking on the course profile of a chosen user. Badges are visible in the short (course) profile.

==Course administration settings==
*A teacher can add and manage badges in their course if the administrator has enabled course badges in ''Administration>Site administration>Badges settings.''
*They will see a link to badges in ''Administration>Course administration>Badges.'' where badges may be [[Managing badges| managed]] and added.

==Site administration settings==
*Badges are enabled by default and can be disabled in ''Administration>Site administration>Advanced features.'' (Note that disabling the feature once badges have been awarded does not prevent those badges being verified by external backpacks.)
*The site settings for badges are located in ''Administration>Site administration>Badges>Badges settings''
===Default badge issuer===
Here you set the name and email address of the issuer. The name will appear where the badges are displayed and might typically be the name of the organization.
===Salt for hashing recipient's email address===
If a hash is used (numbers and letters only) then backpack services can confirm a badge earner without exposing their email address.
===Enable connection to external backpacks===
This should be enabled in order to connect to, for example [http://openbadges.org/ Mozilla Open Badges]. Note that this will not work on a Moodle hosted locally/offline.
===Enable course badges===
Ticking this box will allow teachers to add and manage badges in their courses.

==Badges capabilities==
There are a number of capabilities associated with badges:

*[[Capabilities/block/badges:addinstance|Add a new My latest badges block]]
*[[Capabilities/block/badges:myaddinstance|Add a new My latest badges block to My home]]
*[[Capabilities/moodle/badges:awardbadge| Award a badge]]
*[[Capabilities/moodle/badges:configurecriteria|Set up criteria for awarding a badge]]
*[[Capabilities/moodle/badges:configuredetails|Set up and edit badge details]]
*[[Capabilities/moodle/badges:configuremessages|Configure badges messages]]
*[[Capabilities/moodle/badges:createbadge| Create or duplicate badges]]
*[[Capabilities/moodle/badges:deletebadge| Delete badges]]
*[[Capabilities/moodle/badges:earnbadge|Earn badges]]
*[[Capabilities/moodle/badges:manageglobalsettings | Manage badges site administration settings]]
*[[Capabilities/moodle/badges:manageownbadges|View and manage your own earned badges]]
*[[Capabilities/moodle/badges:viewawarded|View users who earned a specific badge without being able to award a badge]]
*[[Capabilities/moodle/badges:viewbadges |View badges without earning them]]
*[[Capabilities/moodle/badges:viewotherbadges|View public badges in other users' profiles]]

[[de:Auszeichnungen konfigurieren]]
[[es:Configuraciones de insignias]]
[[ja:バッジ設定]]

Badges settings

2014-06-19T15:15:57Z

Mits: ja link

Capabilities/moodle/badges:viewotherbadges

2014-06-14T15:11:32Z

Mits: ja link

{{Capabilities}}
* This allows a user to view public [[Badges|badges]] in other users' profiles
* This capability is allowed for the default role of authenticated user

[[Category:Badges]]
[[Category:Capabilities|Badges]]

[[ja:ケイパビリティ/moodle/バッジ:viewotherbadges]]

Capabilities/moodle/badges:viewbadges

2014-06-10T15:25:03Z

Mits: ja link

{{Capabilities}}
* This allows a user to view [[Badges|badges]] without earning them
* This capability is allowed for the default roles of manager, student and authenticated user

[[Category:Badges]]
[[Category:Capabilities|Badges]]

[[ja:ケイパビリティ/moodle/バッジ:viewbadges]]

Capabilities/moodle/badges:viewawarded

2014-06-08T07:24:37Z

Mits: ja link

{{Capabilities}}
* This allows a user to view users who earned a specific [[Badges|badge]] without being able to award a badge
* This capability is allowed for the default roles of manager, teacher and non-editing teacher

[[Category:Badges]]
[[Category:Capabilities|Badges]]

[[ja:ケイパビリティ/moodle/バッジ:viewawarded]]

Capabilities/moodle/badges:manageownbadges

2014-06-03T21:29:23Z

Mits: ja link

{{Capabilities}}
* This allows a user to view and manage their own earned [[Badges|badges]]
* This capability is allowed for the default role of authenticated user

[[Category:Badges]]
[[Category:Capabilities|Badges]]

[[ja:ケイパビリティ/moodle/バッジ:manageownbadges]]