MoodleDocs - User contributions [en]

Installing Moodle

2020-05-17T13:21:05Z

Howardsmiller: /* See also */

{{Template:Installing Moodle}}
''This page explains how to install Moodle. If you are an expert and/or in a hurry try [[Installation Quickstart]].''

If you just want to try Moodle on a standalone machine there are 'one-click' installers for Windows (see [[Complete install packages for Windows]]) and for OSX (see [[Complete Install Packages for Mac OS X]]) or [[ install on OS X]]. These are unsuitable for production servers.

If you want to avoid installing Moodle yourself completely, consider https://moodlecloud.com/

== Requirements ==

Moodle is primarily developed in Linux using [[Apache]], [[PostgreSQL]]/[[MySQL]]/[[MariaDB]] and [[PHP]] (sometimes known as the LAMP platform). Typically this is also how Moodle is run, although there are other options as long as the software requirements of the [{{Release notes}} release] are met.

If you are installing Moodle in a Windows server, note that from php5.5 onwards, you will also need to have the Visual C++ Redistributable for Visual Studio 2012 installed from:
http://www.microsoft.com/en-us/download/details.aspx?id=30679 Visual C++] ( x86 or x64)

The basic requirements for Moodle are as follows:

=== Hardware ===
* Disk space: 200MB for the Moodle code, plus as much as you need to store content. 5GB is probably a realistic minimum.
* Processor: 1GHz (min), 2GHz dual core or more recommended.
* Memory: 512MB (min), 1GB or more is recommended. 8GB plus is likely on a large production server
* Consider separate servers for the web "front ends" and the database. It is much easier to "tune"

All the above requirements will vary depending on specific hardware and software combinations as well as the type of use and load; busy sites may well require additional resources. Further guidance can be found under [[Performance_recommendations|performance recommendations]]. Moodle scales easily by increasing hardware.

For very large sites, you are much better starting with a small pilot and gaining some experience and insight. A "what hardware do I need for 50,000 user?" style post in the forums is highly unlikely to get a useful answer.

=== Software ===

See the [{{Release notes}} release notes] in the dev docs for software requirements.

== Set up your server ==

Depending on the use case a Moodle server may be anything from a Desktop PC (e.g. for testing and evaluating) to a rackmounted or [[Server cluster|clustered]] solution to cloud VMs or other hosted solutions. As mentioned above there are lots of possibilities for installing the basic server software, some links and pointers are at [[Installing AMP]], [[Internet_Information_Services|IIS]], [[Nginx]].

It will help hugely, regardless of your deployment choices, if time is taken to understand how to configure the different parts of your software stack (HTTP daemon, database, PHP etc). Do not expect the standard server configuration to be optimal for Moodle. For example, the web server and database servers will almost certainly require tuning to get the best out of Moodle.

If a hosting provider is being used ensure that all Moodle [{{Release notes}}#Server_requirements requirements] (such as PHP version) are met by the hosting platform before attempting the installation. It will help to become familiar with changing settings within the hosting provider's platform (e.g. PHP file upload maximums) as the options and tools provided vary.

== Download and copy files into place ==

'''IMPORTANT: While there are now a number of places you can get the Moodle code (including host provided Moodle installers), you are strongly advised to only obtain Moodle from moodle.org. If you run into problems it will be a great deal easier to support you.'''

You have two options:
* Download your required version from http://moodle.org/downloads and unzip/unpack...
* '''OR''' Pull the code from the Git repository (recommended for developers and also makes upgrading very simple):
<pre>
$ git clone -b MOODLE_{{Version3}}_STABLE git://git.moodle.org/moodle.git
</pre>

For a fuller discussion see [[Git for Administrators]].

Either of the above should result in a directory called '''moodle''', containing a number of files and folders.

You can typically place the whole folder in your web server documents directory, in which case the site will be located at '''<nowiki>http://yourwebserver.com/moodle</nowiki>''', or you can copy all the contents straight into the main web server documents directory, in which case the site will be simply '''<nowiki>http://yourwebserver.com</nowiki>'''. See the documentation for your system and/or web server if you are unsure.

:''Tip:'' If you are downloading Moodle to your local computer and then uploading it to your hosted web site, if possible upload the compressed file and decompress at the remote end (check your 'file manager'). Failing that, watch FTP progress carefully for errors or missed files.

* '''Secure the Moodle files:''' It is vital that the files are not writeable by the web server user. For example, on Unix/Linux (as root):
<pre>
chown -R root /path/to/moodle
chmod -R 0755 /path/to/moodle
</pre>
(files are owned by the administrator/superuser and are only writeable by them - readable by everyone else)

On test/dev sites you ''may'' want to make the files writeable in order to use the built in plugin installer. This is discouraged for live sites (at least, revert to more secure settings if you do).

== Create an empty database ==

Next create a new, empty database for your installation. You need to find and make a note of following information for use during the final installation stage:
* '''dbhost''' - the database server hostname. Probably ''localhost'' if the database and web server are the same machine, otherwise the name of the database server
* '''dbname''' - the database name. Whatever you called it, e.g. ''moodle''
* '''dbuser''' - the username for the database. Whatever you assigned, e.g. ''moodleuser'' - do not use the root/superuser account. Create a proper account with the minimum permissions needed.
* '''dbpass''' - the password for the above user

If your site is hosted you should find a web-based administration page for databases as part of the control panel (or ask your administrator). For everyone else or for detailed instructions, see the page for your chosen database server:
* [[PostgreSQL]] (recommended)
* [[MariaDB]] (recommended)
* [[MySQL]]
* [[MSSQL]]
* [[Oracle]] (not recommended)

== Create the (''moodledata'') data directory ==

Moodle requires a directory to store all of its files (all your site's uploaded files, temporary data, cache, session data etc.). The web server needs to be able to write to this directory. On larger systems consider how much free space you are going to use when allocating this directory.

Due to the default way Moodle caches data you may have serious performance issues if you use relatively slow storage (e.g. NFS) for this directory. Read the [[Performance_recommendations]] carefully and consider using (e.g.) redis or memcached for [[Caching]].

'''IMPORTANT:''' This directory must '''NOT''' be accessible directly via the web. This would be a serious security hole. Do not try to place it inside your web root or inside your Moodle program files directory. Moodle will not install. It can go anywhere else convenient.

Here is an example (Unix/Linux) of creating the directory and setting the permissions for '''anyone''' on the server to write here. This is only appropriate for Moodle servers that are not shared. Discuss this with your server administrator for better permissions that just allow the web server user to access these files.

<pre>
# mkdir /path/to/moodledata
# chmod 0777 /path/to/moodledata
</pre>

==== Securing moodledata in a web directory ====

If you are using a hosted site and you have no option but to place 'moodledata' in a web accessible directory. You may be able to secure it by creating an .htaccess file in the 'moodledata' directory. This does not work on all systems - see your host/administrator. Create a file called .htaccess containing only the following lines:
<pre>
order deny,allow
deny from all
</pre>

== Start Moodle install ==
It's now time to run the installer to create the database tables and configure your new site. The recommended method is to use the command line installer. If you cannot do this for any reason (e.g. on a Windows server) the web-based installer is still available.

=== Command line installer ===

It's best to run the command line as your system's web user. You need to know what that is - see your system's documentation (e.g. Ubuntu/Debian is 'www-data', Centos is 'apache')

* Example of using the command-line (as root - substitute 'www-data' for your web user):
<pre>
# chown www-data /path/to/moodle
# cd /path/to/moodle/admin/cli
# sudo -u www-data /usr/bin/php install.php
# chown -R root /path/to/moodle
</pre>
The chowns allow the script to write a new config.php file. More information about the options can be found using
<pre>
# php install.php --help
</pre>

You will be asked for other settings that have not been discussed on this page - if unsure just accept the defaults. For a full discussion see [[Administration via command line]]

=== Web based installer ===

For ease of use you can install Moodle via the web. We recommend configuring your web server so that the page is not publicly accessible until the installation is complete.

To run the web installer script, just go to your Moodle's main URL using a web browser.

The installation process will take you through a number of pages. You should be asked to confirm the copyright, see the database tables being created, supply administrator account details and supply the site details. The database creation can take some time - please be patient. You should eventually end up at the Moodle front page with an invitation to create a new course.

It is very likely that you will be asked to download the new config.php file and upload it to your Moodle installation - just follow the on-screen instructions.

==Final configuration==

=== Settings within Moodle ===
There are a number of options within the Moodle Site Administration screens (accessible from the 'Site administration' tab in the 'Administration' block (Classic theme) or the Site administration button in the navigation bar (Boost). Here are a few of the more important ones that you will probably want to check:
* ''Administration > Site administration > Server > Email > Outgoing mail configuration'': Set your smtp server and authentication if required (so your Moodle site can send emails). You can also set a norepy email on this page.
* ''Administration > Site administration > Server > Server > Support contact''. Set your support contact email.
* ''Administration > Site administration > Server > System paths'': Set the paths to du, dot and aspell binaries.
* ''Administration > Site administration > Server > HTTP'': If you are behind a firewall you may need to set your proxy credentials in the 'Web proxy' section.
* ''Administration > Site administration > Location > Update timezones'': Run this to make sure your timezone information is up to date. (more info [[Location]])
** [http://php.net/manual/en/timezones.php Set server's local timezone] inside <tt>php.ini</tt> (should probably be inside <tt>/etc/php.ini</tt> or <tt>/etc/php.d/date.ini</tt>, depending on the underlying OS):
<code php>
[Date]
; Defines the default timezone used by the date functions
date.timezone = "YOUR LOCAL TIMEZONE"
</code>

=== Remaining tasks ===

* '''Configure Cron''': Moodle's background tasks (e.g. sending out forum emails and performing course backups) are performed by a script which you can set to execute at specific times of the day. This is known as a cron script. Please refer to the [[Cron|Cron instructions]].
* '''Set up backups''': See [[Site backup]] and [[Automated course backup]].
* '''Secure your Moodle site''': Read the [[Security recommendations]].
*'''Increasing the maximum upload size''' See [[Installation FAQ]] Maximum upload file size - how to change it?
* '''Check mail works''' : From Site administration > Server > Test outgoing mail configuration, use the link to send yourself a test email. Don't be tempted to skip this step.

=== Installation is complete :) ===

* Create a new course: You can now access Moodle through your web browser (using the same URL as you set during the install process), log in as your admin user and creatse a new course. See [[Adding a new course|create a new course]].

=== If something goes wrong... ===

Here are some things you should try...

* Check the [[Installation FAQ]]
* Check your file permissions carefully. Can your web server read (but not write) the Moodle program files? Can your web server read and write your Moodle data directory? If you don't fully understand how file ownership and permissions work on your operating system it would be time very well spent to find out.
* Check your database permissions. Have you set up your database user with the correct rights and permissions for your configuration (especially if the web server and database server are different machines)?
* Create your [[Configuration file]] (config.php) by hand. Copy config-dist.php (in the root of the Moodle program directory) to config.php, edit it and set your database/site options there. Installation will continue from the right place.
* Once you have a config.php (see previous tip) you can edit it to turn on debugging (in section 8). This may give you extra information to help track down a problem. If you have access, check your web server error log(s).
* Re-check your php.ini / .htaccess settings. Are they appropriate (e.g. memory_limit), did you edit the correct php.ini / .htaccess file and (if required) did you re-start the web server after making changes?
* Did you include any non-core (optional) plugins, themes or other code before starting the installation script? If so, remove it and try again (it may be broken or incompatible).
* Explain your problem in the [http://moodle.org/mod/forum/view.php?id=28 Installation problems forum]. '''PLEASE''' list your software versions; explain what you did, what happened and what error messages you saw (if any); explain what you tried. There is no such thing as 'nothing', even a blank page is something!

== Platform specific instructions ==

'''Note:''' Much of this information is provided by the community. It may not have been checked and may be out of date. Please read in conjunction with the above installation instructions.

* [[Windows installation]]
** [[Installing Moodle on SmarterASP.NET]]
* [[Unix or Linux Installation]]
* [[Mac Installation]]
* [[Amazon EC2 Cloud Services Installation]]

== See also ==
* [http://www.slideshare.net/gb2048/my-own-moodle Slideshare presentation by Gareth Barnard on installing a local installation of Moodle] and accompanying [https://drive.google.com/folderview?id=0B17B0rYH2zERU21sQnVweUZCUFk&usp=sharing help guides]
* [http://moodle.org/mod/forum/discuss.php?d=182086 New Video Tutorial- How to Install Moodle on Shared Hosting via cPanel (Not Fantastico)]
* [https://moodle.org/mod/forum/discuss.php?d=401983 Another one for cPanel using videos]
* [http://moodle.org/mod/forum/discuss.php?d=199542 Video Tutorial - Install Moodle on a Virtual Box from scratch]

[[es:Instalaci%C3%B3n_de_moodle]]
[[de:Installation von Moodle]]
[[fr:Installation de Moodle]]
[[ja:Moodleのインストール]]

Installing Moodle

2020-05-11T12:14:14Z

Howardsmiller:

{{Template:Installing Moodle}}
''This page explains how to install Moodle. If you are an expert and/or in a hurry try [[Installation Quickstart]].''

If you just want to try Moodle on a standalone machine there are 'one-click' installers for Windows (see [[Complete install packages for Windows]]) and for OSX (see [[Complete Install Packages for Mac OS X]]) or [[ install on OS X]]. These are unsuitable for production servers.

If you want to avoid installing Moodle yourself completely, consider https://moodlecloud.com/

== Requirements ==

Moodle is primarily developed in Linux using [[Apache]], [[PostgreSQL]]/[[MySQL]]/[[MariaDB]] and [[PHP]] (sometimes known as the LAMP platform). Typically this is also how Moodle is run, although there are other options as long as the software requirements of the [{{Release notes}} release] are met.

If you are installing Moodle in a Windows server, note that from php5.5 onwards, you will also need to have the Visual C++ Redistributable for Visual Studio 2012 installed from:
http://www.microsoft.com/en-us/download/details.aspx?id=30679 Visual C++] ( x86 or x64)

The basic requirements for Moodle are as follows:

=== Hardware ===
* Disk space: 200MB for the Moodle code, plus as much as you need to store content. 5GB is probably a realistic minimum.
* Processor: 1GHz (min), 2GHz dual core or more recommended.
* Memory: 512MB (min), 1GB or more is recommended. 8GB plus is likely on a large production server
* Consider separate servers for the web "front ends" and the database. It is much easier to "tune"

All the above requirements will vary depending on specific hardware and software combinations as well as the type of use and load; busy sites may well require additional resources. Further guidance can be found under [[Performance_recommendations|performance recommendations]]. Moodle scales easily by increasing hardware.

For very large sites, you are much better starting with a small pilot and gaining some experience and insight. A "what hardware do I need for 50,000 user?" style post in the forums is highly unlikely to get a useful answer.

=== Software ===

See the [{{Release notes}} release notes] in the dev docs for software requirements.

== Set up your server ==

Depending on the use case a Moodle server may be anything from a Desktop PC (e.g. for testing and evaluating) to a rackmounted or [[Server cluster|clustered]] solution to cloud VMs or other hosted solutions. As mentioned above there are lots of possibilities for installing the basic server software, some links and pointers are at [[Installing AMP]], [[Internet_Information_Services|IIS]], [[Nginx]].

It will help hugely, regardless of your deployment choices, if time is taken to understand how to configure the different parts of your software stack (HTTP daemon, database, PHP etc). Do not expect the standard server configuration to be optimal for Moodle. For example, the web server and database servers will almost certainly require tuning to get the best out of Moodle.

If a hosting provider is being used ensure that all Moodle [{{Release notes}}#Server_requirements requirements] (such as PHP version) are met by the hosting platform before attempting the installation. It will help to become familiar with changing settings within the hosting provider's platform (e.g. PHP file upload maximums) as the options and tools provided vary.

== Download and copy files into place ==

'''IMPORTANT: While there are now a number of places you can get the Moodle code (including host provided Moodle installers), you are strongly advised to only obtain Moodle from moodle.org. If you run into problems it will be a great deal easier to support you.'''

You have two options:
* Download your required version from http://moodle.org/downloads and unzip/unpack...
* '''OR''' Pull the code from the Git repository (recommended for developers and also makes upgrading very simple):
<pre>
$ git clone -b MOODLE_{{Version3}}_STABLE git://git.moodle.org/moodle.git
</pre>

For a fuller discussion see [[Git for Administrators]].

Either of the above should result in a directory called '''moodle''', containing a number of files and folders.

You can typically place the whole folder in your web server documents directory, in which case the site will be located at '''<nowiki>http://yourwebserver.com/moodle</nowiki>''', or you can copy all the contents straight into the main web server documents directory, in which case the site will be simply '''<nowiki>http://yourwebserver.com</nowiki>'''. See the documentation for your system and/or web server if you are unsure.

:''Tip:'' If you are downloading Moodle to your local computer and then uploading it to your hosted web site, if possible upload the compressed file and decompress at the remote end (check your 'file manager'). Failing that, watch FTP progress carefully for errors or missed files.

* '''Secure the Moodle files:''' It is vital that the files are not writeable by the web server user. For example, on Unix/Linux (as root):
<pre>
chown -R root /path/to/moodle
chmod -R 0755 /path/to/moodle
</pre>
(files are owned by the administrator/superuser and are only writeable by them - readable by everyone else)

On test/dev sites you ''may'' want to make the files writeable in order to use the built in plugin installer. This is discouraged for live sites (at least, revert to more secure settings if you do).

== Create an empty database ==

Next create a new, empty database for your installation. You need to find and make a note of following information for use during the final installation stage:
* '''dbhost''' - the database server hostname. Probably ''localhost'' if the database and web server are the same machine, otherwise the name of the database server
* '''dbname''' - the database name. Whatever you called it, e.g. ''moodle''
* '''dbuser''' - the username for the database. Whatever you assigned, e.g. ''moodleuser'' - do not use the root/superuser account. Create a proper account with the minimum permissions needed.
* '''dbpass''' - the password for the above user

If your site is hosted you should find a web-based administration page for databases as part of the control panel (or ask your administrator). For everyone else or for detailed instructions, see the page for your chosen database server:
* [[PostgreSQL]] (recommended)
* [[MariaDB]] (recommended)
* [[MySQL]]
* [[MSSQL]]
* [[Oracle]] (not recommended)

== Create the (''moodledata'') data directory ==

Moodle requires a directory to store all of its files (all your site's uploaded files, temporary data, cache, session data etc.). The web server needs to be able to write to this directory. On larger systems consider how much free space you are going to use when allocating this directory.

Due to the default way Moodle caches data you may have serious performance issues if you use relatively slow storage (e.g. NFS) for this directory. Read the [[Performance_recommendations]] carefully and consider using (e.g.) redis or memcached for [[Caching]].

'''IMPORTANT:''' This directory must '''NOT''' be accessible directly via the web. This would be a serious security hole. Do not try to place it inside your web root or inside your Moodle program files directory. Moodle will not install. It can go anywhere else convenient.

Here is an example (Unix/Linux) of creating the directory and setting the permissions for '''anyone''' on the server to write here. This is only appropriate for Moodle servers that are not shared. Discuss this with your server administrator for better permissions that just allow the web server user to access these files.

<pre>
# mkdir /path/to/moodledata
# chmod 0777 /path/to/moodledata
</pre>

==== Securing moodledata in a web directory ====

If you are using a hosted site and you have no option but to place 'moodledata' in a web accessible directory. You may be able to secure it by creating an .htaccess file in the 'moodledata' directory. This does not work on all systems - see your host/administrator. Create a file called .htaccess containing only the following lines:
<pre>
order deny,allow
deny from all
</pre>

== Start Moodle install ==
It's now time to run the installer to create the database tables and configure your new site. The recommended method is to use the command line installer. If you cannot do this for any reason (e.g. on a Windows server) the web-based installer is still available.

=== Command line installer ===

It's best to run the command line as your system's web user. You need to know what that is - see your system's documentation (e.g. Ubuntu/Debian is 'www-data', Centos is 'apache')

* Example of using the command-line (as root - substitute 'www-data' for your web user):
<pre>
# chown www-data /path/to/moodle
# cd /path/to/moodle/admin/cli
# sudo -u www-data /usr/bin/php install.php
# chown -R root /path/to/moodle
</pre>
The chowns allow the script to write a new config.php file. More information about the options can be found using
<pre>
# php install.php --help
</pre>

You will be asked for other settings that have not been discussed on this page - if unsure just accept the defaults. For a full discussion see [[Administration via command line]]

=== Web based installer ===

For ease of use you can install Moodle via the web. We recommend configuring your web server so that the page is not publicly accessible until the installation is complete.

To run the web installer script, just go to your Moodle's main URL using a web browser.

The installation process will take you through a number of pages. You should be asked to confirm the copyright, see the database tables being created, supply administrator account details and supply the site details. The database creation can take some time - please be patient. You should eventually end up at the Moodle front page with an invitation to create a new course.

It is very likely that you will be asked to download the new config.php file and upload it to your Moodle installation - just follow the on-screen instructions.

==Final configuration==

=== Settings within Moodle ===
There are a number of options within the Moodle Site Administration screens (accessible from the 'Site administration' tab in the 'Administration' block (Classic theme) or the Site administration button in the navigation bar (Boost). Here are a few of the more important ones that you will probably want to check:
* ''Administration > Site administration > Server > Email > Outgoing mail configuration'': Set your smtp server and authentication if required (so your Moodle site can send emails). You can also set a norepy email on this page.
* ''Administration > Site administration > Server > Server > Support contact''. Set your support contact email.
* ''Administration > Site administration > Server > System paths'': Set the paths to du, dot and aspell binaries.
* ''Administration > Site administration > Server > HTTP'': If you are behind a firewall you may need to set your proxy credentials in the 'Web proxy' section.
* ''Administration > Site administration > Location > Update timezones'': Run this to make sure your timezone information is up to date. (more info [[Location]])
** [http://php.net/manual/en/timezones.php Set server's local timezone] inside <tt>php.ini</tt> (should probably be inside <tt>/etc/php.ini</tt> or <tt>/etc/php.d/date.ini</tt>, depending on the underlying OS):
<code php>
[Date]
; Defines the default timezone used by the date functions
date.timezone = "YOUR LOCAL TIMEZONE"
</code>

=== Remaining tasks ===

* '''Configure Cron''': Moodle's background tasks (e.g. sending out forum emails and performing course backups) are performed by a script which you can set to execute at specific times of the day. This is known as a cron script. Please refer to the [[Cron|Cron instructions]].
* '''Set up backups''': See [[Site backup]] and [[Automated course backup]].
* '''Secure your Moodle site''': Read the [[Security recommendations]].
*'''Increasing the maximum upload size''' See [[Installation FAQ]] Maximum upload file size - how to change it?
* '''Check mail works''' : From Site administration > Server > Test outgoing mail configuration, use the link to send yourself a test email. Don't be tempted to skip this step.

=== Installation is complete :) ===

* Create a new course: You can now access Moodle through your web browser (using the same URL as you set during the install process), log in as your admin user and creatse a new course. See [[Adding a new course|create a new course]].

=== If something goes wrong... ===

Here are some things you should try...

* Check the [[Installation FAQ]]
* Check your file permissions carefully. Can your web server read (but not write) the Moodle program files? Can your web server read and write your Moodle data directory? If you don't fully understand how file ownership and permissions work on your operating system it would be time very well spent to find out.
* Check your database permissions. Have you set up your database user with the correct rights and permissions for your configuration (especially if the web server and database server are different machines)?
* Create your [[Configuration file]] (config.php) by hand. Copy config-dist.php (in the root of the Moodle program directory) to config.php, edit it and set your database/site options there. Installation will continue from the right place.
* Once you have a config.php (see previous tip) you can edit it to turn on debugging (in section 8). This may give you extra information to help track down a problem. If you have access, check your web server error log(s).
* Re-check your php.ini / .htaccess settings. Are they appropriate (e.g. memory_limit), did you edit the correct php.ini / .htaccess file and (if required) did you re-start the web server after making changes?
* Did you include any non-core (optional) plugins, themes or other code before starting the installation script? If so, remove it and try again (it may be broken or incompatible).
* Explain your problem in the [http://moodle.org/mod/forum/view.php?id=28 Installation problems forum]. '''PLEASE''' list your software versions; explain what you did, what happened and what error messages you saw (if any); explain what you tried. There is no such thing as 'nothing', even a blank page is something!

== Platform specific instructions ==

'''Note:''' Much of this information is provided by the community. It may not have been checked and may be out of date. Please read in conjunction with the above installation instructions.

* [[Windows installation]]
** [[Installing Moodle on SmarterASP.NET]]
* [[Unix or Linux Installation]]
* [[Mac Installation]]
* [[Amazon EC2 Cloud Services Installation]]

== See also ==
* [http://www.slideshare.net/gb2048/my-own-moodle Slideshare presentation by Gareth Barnard on installing a local installation of Moodle] and accompanying [https://drive.google.com/folderview?id=0B17B0rYH2zERU21sQnVweUZCUFk&usp=sharing help guides]
* [http://moodle.org/mod/forum/discuss.php?d=182086 New Video Tutorial- How to Install Moodle on Shared Hosting via cPanel (Not Fantastico)]
* [http://moodle.org/mod/forum/discuss.php?d=199542 Video Tutorial - Install Moodle on a Virtual Box from scratch]

[[es:Instalaci%C3%B3n_de_moodle]]
[[de:Installation von Moodle]]
[[fr:Installation de Moodle]]
[[ja:Moodleのインストール]]

Installing Moodle

2020-05-11T12:13:12Z

Howardsmiller: /* Set up your server */

{{Template:Installing Moodle}}
''This page explains how to install Moodle. If you are an expert and/or in a hurry try [[Installation Quickstart]].''

If you just want to try Moodle on a standalone machine there are 'one-click' installers for Windows (see [[Complete install packages for Windows]]) and for OSX (see [[Complete Install Packages for Mac OS X]]) or [[ install on OS X]]. These are unsuitable for production servers.

== Requirements ==

Moodle is primarily developed in Linux using [[Apache]], [[PostgreSQL]]/[[MySQL]]/[[MariaDB]] and [[PHP]] (sometimes known as the LAMP platform). Typically this is also how Moodle is run, although there are other options as long as the software requirements of the [{{Release notes}} release] are met.

If you are installing Moodle in a Windows server, note that from php5.5 onwards, you will also need to have the Visual C++ Redistributable for Visual Studio 2012 installed from:
http://www.microsoft.com/en-us/download/details.aspx?id=30679 Visual C++] ( x86 or x64)

The basic requirements for Moodle are as follows:

=== Hardware ===
* Disk space: 200MB for the Moodle code, plus as much as you need to store content. 5GB is probably a realistic minimum.
* Processor: 1GHz (min), 2GHz dual core or more recommended.
* Memory: 512MB (min), 1GB or more is recommended. 8GB plus is likely on a large production server
* Consider separate servers for the web "front ends" and the database. It is much easier to "tune"

All the above requirements will vary depending on specific hardware and software combinations as well as the type of use and load; busy sites may well require additional resources. Further guidance can be found under [[Performance_recommendations|performance recommendations]]. Moodle scales easily by increasing hardware.

For very large sites, you are much better starting with a small pilot and gaining some experience and insight. A "what hardware do I need for 50,000 user?" style post in the forums is highly unlikely to get a useful answer.

=== Software ===

See the [{{Release notes}} release notes] in the dev docs for software requirements.

== Set up your server ==

Depending on the use case a Moodle server may be anything from a Desktop PC (e.g. for testing and evaluating) to a rackmounted or [[Server cluster|clustered]] solution to cloud VMs or other hosted solutions. As mentioned above there are lots of possibilities for installing the basic server software, some links and pointers are at [[Installing AMP]], [[Internet_Information_Services|IIS]], [[Nginx]].

It will help hugely, regardless of your deployment choices, if time is taken to understand how to configure the different parts of your software stack (HTTP daemon, database, PHP etc). Do not expect the standard server configuration to be optimal for Moodle. For example, the web server and database servers will almost certainly require tuning to get the best out of Moodle.

If a hosting provider is being used ensure that all Moodle [{{Release notes}}#Server_requirements requirements] (such as PHP version) are met by the hosting platform before attempting the installation. It will help to become familiar with changing settings within the hosting provider's platform (e.g. PHP file upload maximums) as the options and tools provided vary.

== Download and copy files into place ==

'''IMPORTANT: While there are now a number of places you can get the Moodle code (including host provided Moodle installers), you are strongly advised to only obtain Moodle from moodle.org. If you run into problems it will be a great deal easier to support you.'''

You have two options:
* Download your required version from http://moodle.org/downloads and unzip/unpack...
* '''OR''' Pull the code from the Git repository (recommended for developers and also makes upgrading very simple):
<pre>
$ git clone -b MOODLE_{{Version3}}_STABLE git://git.moodle.org/moodle.git
</pre>

For a fuller discussion see [[Git for Administrators]].

Either of the above should result in a directory called '''moodle''', containing a number of files and folders.

You can typically place the whole folder in your web server documents directory, in which case the site will be located at '''<nowiki>http://yourwebserver.com/moodle</nowiki>''', or you can copy all the contents straight into the main web server documents directory, in which case the site will be simply '''<nowiki>http://yourwebserver.com</nowiki>'''. See the documentation for your system and/or web server if you are unsure.

:''Tip:'' If you are downloading Moodle to your local computer and then uploading it to your hosted web site, if possible upload the compressed file and decompress at the remote end (check your 'file manager'). Failing that, watch FTP progress carefully for errors or missed files.

* '''Secure the Moodle files:''' It is vital that the files are not writeable by the web server user. For example, on Unix/Linux (as root):
<pre>
chown -R root /path/to/moodle
chmod -R 0755 /path/to/moodle
</pre>
(files are owned by the administrator/superuser and are only writeable by them - readable by everyone else)

On test/dev sites you ''may'' want to make the files writeable in order to use the built in plugin installer. This is discouraged for live sites (at least, revert to more secure settings if you do).

== Create an empty database ==

Next create a new, empty database for your installation. You need to find and make a note of following information for use during the final installation stage:
* '''dbhost''' - the database server hostname. Probably ''localhost'' if the database and web server are the same machine, otherwise the name of the database server
* '''dbname''' - the database name. Whatever you called it, e.g. ''moodle''
* '''dbuser''' - the username for the database. Whatever you assigned, e.g. ''moodleuser'' - do not use the root/superuser account. Create a proper account with the minimum permissions needed.
* '''dbpass''' - the password for the above user

If your site is hosted you should find a web-based administration page for databases as part of the control panel (or ask your administrator). For everyone else or for detailed instructions, see the page for your chosen database server:
* [[PostgreSQL]] (recommended)
* [[MariaDB]] (recommended)
* [[MySQL]]
* [[MSSQL]]
* [[Oracle]] (not recommended)

== Create the (''moodledata'') data directory ==

Moodle requires a directory to store all of its files (all your site's uploaded files, temporary data, cache, session data etc.). The web server needs to be able to write to this directory. On larger systems consider how much free space you are going to use when allocating this directory.

Due to the default way Moodle caches data you may have serious performance issues if you use relatively slow storage (e.g. NFS) for this directory. Read the [[Performance_recommendations]] carefully and consider using (e.g.) redis or memcached for [[Caching]].

'''IMPORTANT:''' This directory must '''NOT''' be accessible directly via the web. This would be a serious security hole. Do not try to place it inside your web root or inside your Moodle program files directory. Moodle will not install. It can go anywhere else convenient.

Here is an example (Unix/Linux) of creating the directory and setting the permissions for '''anyone''' on the server to write here. This is only appropriate for Moodle servers that are not shared. Discuss this with your server administrator for better permissions that just allow the web server user to access these files.

<pre>
# mkdir /path/to/moodledata
# chmod 0777 /path/to/moodledata
</pre>

==== Securing moodledata in a web directory ====

If you are using a hosted site and you have no option but to place 'moodledata' in a web accessible directory. You may be able to secure it by creating an .htaccess file in the 'moodledata' directory. This does not work on all systems - see your host/administrator. Create a file called .htaccess containing only the following lines:
<pre>
order deny,allow
deny from all
</pre>

== Start Moodle install ==
It's now time to run the installer to create the database tables and configure your new site. The recommended method is to use the command line installer. If you cannot do this for any reason (e.g. on a Windows server) the web-based installer is still available.

=== Command line installer ===

It's best to run the command line as your system's web user. You need to know what that is - see your system's documentation (e.g. Ubuntu/Debian is 'www-data', Centos is 'apache')

* Example of using the command-line (as root - substitute 'www-data' for your web user):
<pre>
# chown www-data /path/to/moodle
# cd /path/to/moodle/admin/cli
# sudo -u www-data /usr/bin/php install.php
# chown -R root /path/to/moodle
</pre>
The chowns allow the script to write a new config.php file. More information about the options can be found using
<pre>
# php install.php --help
</pre>

You will be asked for other settings that have not been discussed on this page - if unsure just accept the defaults. For a full discussion see [[Administration via command line]]

=== Web based installer ===

For ease of use you can install Moodle via the web. We recommend configuring your web server so that the page is not publicly accessible until the installation is complete.

To run the web installer script, just go to your Moodle's main URL using a web browser.

The installation process will take you through a number of pages. You should be asked to confirm the copyright, see the database tables being created, supply administrator account details and supply the site details. The database creation can take some time - please be patient. You should eventually end up at the Moodle front page with an invitation to create a new course.

It is very likely that you will be asked to download the new config.php file and upload it to your Moodle installation - just follow the on-screen instructions.

==Final configuration==

=== Settings within Moodle ===
There are a number of options within the Moodle Site Administration screens (accessible from the 'Site administration' tab in the 'Administration' block (Classic theme) or the Site administration button in the navigation bar (Boost). Here are a few of the more important ones that you will probably want to check:
* ''Administration > Site administration > Server > Email > Outgoing mail configuration'': Set your smtp server and authentication if required (so your Moodle site can send emails). You can also set a norepy email on this page.
* ''Administration > Site administration > Server > Server > Support contact''. Set your support contact email.
* ''Administration > Site administration > Server > System paths'': Set the paths to du, dot and aspell binaries.
* ''Administration > Site administration > Server > HTTP'': If you are behind a firewall you may need to set your proxy credentials in the 'Web proxy' section.
* ''Administration > Site administration > Location > Update timezones'': Run this to make sure your timezone information is up to date. (more info [[Location]])
** [http://php.net/manual/en/timezones.php Set server's local timezone] inside <tt>php.ini</tt> (should probably be inside <tt>/etc/php.ini</tt> or <tt>/etc/php.d/date.ini</tt>, depending on the underlying OS):
<code php>
[Date]
; Defines the default timezone used by the date functions
date.timezone = "YOUR LOCAL TIMEZONE"
</code>

=== Remaining tasks ===

* '''Configure Cron''': Moodle's background tasks (e.g. sending out forum emails and performing course backups) are performed by a script which you can set to execute at specific times of the day. This is known as a cron script. Please refer to the [[Cron|Cron instructions]].
* '''Set up backups''': See [[Site backup]] and [[Automated course backup]].
* '''Secure your Moodle site''': Read the [[Security recommendations]].
*'''Increasing the maximum upload size''' See [[Installation FAQ]] Maximum upload file size - how to change it?
* '''Check mail works''' : From Site administration > Server > Test outgoing mail configuration, use the link to send yourself a test email. Don't be tempted to skip this step.

=== Installation is complete :) ===

* Create a new course: You can now access Moodle through your web browser (using the same URL as you set during the install process), log in as your admin user and creatse a new course. See [[Adding a new course|create a new course]].

=== If something goes wrong... ===

Here are some things you should try...

* Check the [[Installation FAQ]]
* Check your file permissions carefully. Can your web server read (but not write) the Moodle program files? Can your web server read and write your Moodle data directory? If you don't fully understand how file ownership and permissions work on your operating system it would be time very well spent to find out.
* Check your database permissions. Have you set up your database user with the correct rights and permissions for your configuration (especially if the web server and database server are different machines)?
* Create your [[Configuration file]] (config.php) by hand. Copy config-dist.php (in the root of the Moodle program directory) to config.php, edit it and set your database/site options there. Installation will continue from the right place.
* Once you have a config.php (see previous tip) you can edit it to turn on debugging (in section 8). This may give you extra information to help track down a problem. If you have access, check your web server error log(s).
* Re-check your php.ini / .htaccess settings. Are they appropriate (e.g. memory_limit), did you edit the correct php.ini / .htaccess file and (if required) did you re-start the web server after making changes?
* Did you include any non-core (optional) plugins, themes or other code before starting the installation script? If so, remove it and try again (it may be broken or incompatible).
* Explain your problem in the [http://moodle.org/mod/forum/view.php?id=28 Installation problems forum]. '''PLEASE''' list your software versions; explain what you did, what happened and what error messages you saw (if any); explain what you tried. There is no such thing as 'nothing', even a blank page is something!

== Platform specific instructions ==

'''Note:''' Much of this information is provided by the community. It may not have been checked and may be out of date. Please read in conjunction with the above installation instructions.

* [[Windows installation]]
** [[Installing Moodle on SmarterASP.NET]]
* [[Unix or Linux Installation]]
* [[Mac Installation]]
* [[Amazon EC2 Cloud Services Installation]]

== See also ==
* [http://www.slideshare.net/gb2048/my-own-moodle Slideshare presentation by Gareth Barnard on installing a local installation of Moodle] and accompanying [https://drive.google.com/folderview?id=0B17B0rYH2zERU21sQnVweUZCUFk&usp=sharing help guides]
* [http://moodle.org/mod/forum/discuss.php?d=182086 New Video Tutorial- How to Install Moodle on Shared Hosting via cPanel (Not Fantastico)]
* [http://moodle.org/mod/forum/discuss.php?d=199542 Video Tutorial - Install Moodle on a Virtual Box from scratch]

[[es:Instalaci%C3%B3n_de_moodle]]
[[de:Installation von Moodle]]
[[fr:Installation de Moodle]]
[[ja:Moodleのインストール]]

Installing Moodle

2020-05-11T12:09:34Z

Howardsmiller: Removing a lot of "advanced" fluff from the installation page

{{Template:Installing Moodle}}
''This page explains how to install Moodle. If you are an expert and/or in a hurry try [[Installation Quickstart]].''

If you just want to try Moodle on a standalone machine there are 'one-click' installers for Windows (see [[Complete install packages for Windows]]) and for OSX (see [[Complete Install Packages for Mac OS X]]) or [[ install on OS X]]. These are unsuitable for production servers.

== Requirements ==

Moodle is primarily developed in Linux using [[Apache]], [[PostgreSQL]]/[[MySQL]]/[[MariaDB]] and [[PHP]] (sometimes known as the LAMP platform). Typically this is also how Moodle is run, although there are other options as long as the software requirements of the [{{Release notes}} release] are met.

If you are installing Moodle in a Windows server, note that from php5.5 onwards, you will also need to have the Visual C++ Redistributable for Visual Studio 2012 installed from:
http://www.microsoft.com/en-us/download/details.aspx?id=30679 Visual C++] ( x86 or x64)

The basic requirements for Moodle are as follows:

=== Hardware ===
* Disk space: 200MB for the Moodle code, plus as much as you need to store content. 5GB is probably a realistic minimum.
* Processor: 1GHz (min), 2GHz dual core or more recommended.
* Memory: 512MB (min), 1GB or more is recommended. 8GB plus is likely on a large production server
* Consider separate servers for the web "front ends" and the database. It is much easier to "tune"

All the above requirements will vary depending on specific hardware and software combinations as well as the type of use and load; busy sites may well require additional resources. Further guidance can be found under [[Performance_recommendations|performance recommendations]]. Moodle scales easily by increasing hardware.

For very large sites, you are much better starting with a small pilot and gaining some experience and insight. A "what hardware do I need for 50,000 user?" style post in the forums is highly unlikely to get a useful answer.

=== Software ===

See the [{{Release notes}} release notes] in the dev docs for software requirements.

== Set up your server ==

Depending the use case a Moodle server may be anything from a Desktop PC (e.g. for testing and evaluating) to a rackmounted or [[Server cluster|clustered]] solution. As mentioned above there are lots of possibilities for installing the basic server software, some links and pointers are at [[Installing AMP]], [[Internet_Information_Services|IIS]], [[Nginx]].

It will help hugely, regardless of your deployment choices, if time is taken to understand how to configure the different parts of your software stack (HTTP daemon, database, PHP etc). Do not expect the standard server configuration to be optimal for Moodle. For example, the web server and database servers will almost certainly require tuning to get the best out of Moodle.

If a hosting provider is being used ensure that all Moodle [{{Release notes}}#Server_requirements requirements] (such as PHP version) are met by the hosting platform before attempting the installation. It will help to become familiar with changing settings within the hosting provider's platform (e.g. PHP file upload maximums) as the options and tools provided vary.

== Download and copy files into place ==

'''IMPORTANT: While there are now a number of places you can get the Moodle code (including host provided Moodle installers), you are strongly advised to only obtain Moodle from moodle.org. If you run into problems it will be a great deal easier to support you.'''

You have two options:
* Download your required version from http://moodle.org/downloads and unzip/unpack...
* '''OR''' Pull the code from the Git repository (recommended for developers and also makes upgrading very simple):
<pre>
$ git clone -b MOODLE_{{Version3}}_STABLE git://git.moodle.org/moodle.git
</pre>

For a fuller discussion see [[Git for Administrators]].

Either of the above should result in a directory called '''moodle''', containing a number of files and folders.

You can typically place the whole folder in your web server documents directory, in which case the site will be located at '''<nowiki>http://yourwebserver.com/moodle</nowiki>''', or you can copy all the contents straight into the main web server documents directory, in which case the site will be simply '''<nowiki>http://yourwebserver.com</nowiki>'''. See the documentation for your system and/or web server if you are unsure.

:''Tip:'' If you are downloading Moodle to your local computer and then uploading it to your hosted web site, if possible upload the compressed file and decompress at the remote end (check your 'file manager'). Failing that, watch FTP progress carefully for errors or missed files.

* '''Secure the Moodle files:''' It is vital that the files are not writeable by the web server user. For example, on Unix/Linux (as root):
<pre>
chown -R root /path/to/moodle
chmod -R 0755 /path/to/moodle
</pre>
(files are owned by the administrator/superuser and are only writeable by them - readable by everyone else)

On test/dev sites you ''may'' want to make the files writeable in order to use the built in plugin installer. This is discouraged for live sites (at least, revert to more secure settings if you do).

== Create an empty database ==

Next create a new, empty database for your installation. You need to find and make a note of following information for use during the final installation stage:
* '''dbhost''' - the database server hostname. Probably ''localhost'' if the database and web server are the same machine, otherwise the name of the database server
* '''dbname''' - the database name. Whatever you called it, e.g. ''moodle''
* '''dbuser''' - the username for the database. Whatever you assigned, e.g. ''moodleuser'' - do not use the root/superuser account. Create a proper account with the minimum permissions needed.
* '''dbpass''' - the password for the above user

If your site is hosted you should find a web-based administration page for databases as part of the control panel (or ask your administrator). For everyone else or for detailed instructions, see the page for your chosen database server:
* [[PostgreSQL]] (recommended)
* [[MariaDB]] (recommended)
* [[MySQL]]
* [[MSSQL]]
* [[Oracle]] (not recommended)

== Create the (''moodledata'') data directory ==

Moodle requires a directory to store all of its files (all your site's uploaded files, temporary data, cache, session data etc.). The web server needs to be able to write to this directory. On larger systems consider how much free space you are going to use when allocating this directory.

Due to the default way Moodle caches data you may have serious performance issues if you use relatively slow storage (e.g. NFS) for this directory. Read the [[Performance_recommendations]] carefully and consider using (e.g.) redis or memcached for [[Caching]].

'''IMPORTANT:''' This directory must '''NOT''' be accessible directly via the web. This would be a serious security hole. Do not try to place it inside your web root or inside your Moodle program files directory. Moodle will not install. It can go anywhere else convenient.

Here is an example (Unix/Linux) of creating the directory and setting the permissions for '''anyone''' on the server to write here. This is only appropriate for Moodle servers that are not shared. Discuss this with your server administrator for better permissions that just allow the web server user to access these files.

<pre>
# mkdir /path/to/moodledata
# chmod 0777 /path/to/moodledata
</pre>

==== Securing moodledata in a web directory ====

If you are using a hosted site and you have no option but to place 'moodledata' in a web accessible directory. You may be able to secure it by creating an .htaccess file in the 'moodledata' directory. This does not work on all systems - see your host/administrator. Create a file called .htaccess containing only the following lines:
<pre>
order deny,allow
deny from all
</pre>

== Start Moodle install ==
It's now time to run the installer to create the database tables and configure your new site. The recommended method is to use the command line installer. If you cannot do this for any reason (e.g. on a Windows server) the web-based installer is still available.

=== Command line installer ===

It's best to run the command line as your system's web user. You need to know what that is - see your system's documentation (e.g. Ubuntu/Debian is 'www-data', Centos is 'apache')

* Example of using the command-line (as root - substitute 'www-data' for your web user):
<pre>
# chown www-data /path/to/moodle
# cd /path/to/moodle/admin/cli
# sudo -u www-data /usr/bin/php install.php
# chown -R root /path/to/moodle
</pre>
The chowns allow the script to write a new config.php file. More information about the options can be found using
<pre>
# php install.php --help
</pre>

You will be asked for other settings that have not been discussed on this page - if unsure just accept the defaults. For a full discussion see [[Administration via command line]]

=== Web based installer ===

For ease of use you can install Moodle via the web. We recommend configuring your web server so that the page is not publicly accessible until the installation is complete.

To run the web installer script, just go to your Moodle's main URL using a web browser.

The installation process will take you through a number of pages. You should be asked to confirm the copyright, see the database tables being created, supply administrator account details and supply the site details. The database creation can take some time - please be patient. You should eventually end up at the Moodle front page with an invitation to create a new course.

It is very likely that you will be asked to download the new config.php file and upload it to your Moodle installation - just follow the on-screen instructions.

==Final configuration==

=== Settings within Moodle ===
There are a number of options within the Moodle Site Administration screens (accessible from the 'Site administration' tab in the 'Administration' block (Classic theme) or the Site administration button in the navigation bar (Boost). Here are a few of the more important ones that you will probably want to check:
* ''Administration > Site administration > Server > Email > Outgoing mail configuration'': Set your smtp server and authentication if required (so your Moodle site can send emails). You can also set a norepy email on this page.
* ''Administration > Site administration > Server > Server > Support contact''. Set your support contact email.
* ''Administration > Site administration > Server > System paths'': Set the paths to du, dot and aspell binaries.
* ''Administration > Site administration > Server > HTTP'': If you are behind a firewall you may need to set your proxy credentials in the 'Web proxy' section.
* ''Administration > Site administration > Location > Update timezones'': Run this to make sure your timezone information is up to date. (more info [[Location]])
** [http://php.net/manual/en/timezones.php Set server's local timezone] inside <tt>php.ini</tt> (should probably be inside <tt>/etc/php.ini</tt> or <tt>/etc/php.d/date.ini</tt>, depending on the underlying OS):
<code php>
[Date]
; Defines the default timezone used by the date functions
date.timezone = "YOUR LOCAL TIMEZONE"
</code>

=== Remaining tasks ===

* '''Configure Cron''': Moodle's background tasks (e.g. sending out forum emails and performing course backups) are performed by a script which you can set to execute at specific times of the day. This is known as a cron script. Please refer to the [[Cron|Cron instructions]].
* '''Set up backups''': See [[Site backup]] and [[Automated course backup]].
* '''Secure your Moodle site''': Read the [[Security recommendations]].
*'''Increasing the maximum upload size''' See [[Installation FAQ]] Maximum upload file size - how to change it?
* '''Check mail works''' : From Site administration > Server > Test outgoing mail configuration, use the link to send yourself a test email. Don't be tempted to skip this step.

=== Installation is complete :) ===

* Create a new course: You can now access Moodle through your web browser (using the same URL as you set during the install process), log in as your admin user and creatse a new course. See [[Adding a new course|create a new course]].

=== If something goes wrong... ===

Here are some things you should try...

* Check the [[Installation FAQ]]
* Check your file permissions carefully. Can your web server read (but not write) the Moodle program files? Can your web server read and write your Moodle data directory? If you don't fully understand how file ownership and permissions work on your operating system it would be time very well spent to find out.
* Check your database permissions. Have you set up your database user with the correct rights and permissions for your configuration (especially if the web server and database server are different machines)?
* Create your [[Configuration file]] (config.php) by hand. Copy config-dist.php (in the root of the Moodle program directory) to config.php, edit it and set your database/site options there. Installation will continue from the right place.
* Once you have a config.php (see previous tip) you can edit it to turn on debugging (in section 8). This may give you extra information to help track down a problem. If you have access, check your web server error log(s).
* Re-check your php.ini / .htaccess settings. Are they appropriate (e.g. memory_limit), did you edit the correct php.ini / .htaccess file and (if required) did you re-start the web server after making changes?
* Did you include any non-core (optional) plugins, themes or other code before starting the installation script? If so, remove it and try again (it may be broken or incompatible).
* Explain your problem in the [http://moodle.org/mod/forum/view.php?id=28 Installation problems forum]. '''PLEASE''' list your software versions; explain what you did, what happened and what error messages you saw (if any); explain what you tried. There is no such thing as 'nothing', even a blank page is something!

== Platform specific instructions ==

'''Note:''' Much of this information is provided by the community. It may not have been checked and may be out of date. Please read in conjunction with the above installation instructions.

* [[Windows installation]]
** [[Installing Moodle on SmarterASP.NET]]
* [[Unix or Linux Installation]]
* [[Mac Installation]]
* [[Amazon EC2 Cloud Services Installation]]

== See also ==
* [http://www.slideshare.net/gb2048/my-own-moodle Slideshare presentation by Gareth Barnard on installing a local installation of Moodle] and accompanying [https://drive.google.com/folderview?id=0B17B0rYH2zERU21sQnVweUZCUFk&usp=sharing help guides]
* [http://moodle.org/mod/forum/discuss.php?d=182086 New Video Tutorial- How to Install Moodle on Shared Hosting via cPanel (Not Fantastico)]
* [http://moodle.org/mod/forum/discuss.php?d=199542 Video Tutorial - Install Moodle on a Virtual Box from scratch]

[[es:Instalaci%C3%B3n_de_moodle]]
[[de:Installation von Moodle]]
[[fr:Installation de Moodle]]
[[ja:Moodleのインストール]]

Installing Moodle

2020-05-06T16:20:40Z

Howardsmiller: ACL is too much information here.

{{Template:Installing Moodle}}
''This page explains how to install Moodle. If you are an expert and/or in a hurry try [[Installation Quickstart]].''

If you just want to try Moodle on a standalone machine there are 'one-click' installers for Windows (see [[Complete install packages for Windows]]) and for OSX (see [[Complete Install Packages for Mac OS X]]) or [[ install on OS X]]. These are unsuitable for production servers.

== Requirements ==

Moodle is primarily developed in Linux using [[Apache]], [[PostgreSQL]]/[[MySQL]]/[[MariaDB]] and [[PHP]] (sometimes known as the LAMP platform). Typically this is also how Moodle is run, although there are other options as long as the software requirements of the [{{Release notes}} release] are met.

If you are installing Moodle in a Windows server, note that from php5.5 onwards, you will also need to have the Visual C++ Redistributable for Visual Studio 2012 installed from:
http://www.microsoft.com/en-us/download/details.aspx?id=30679 Visual C++] ( x86 or x64)

The basic requirements for Moodle are as follows:

=== Hardware ===
* Disk space: 200MB for the Moodle code, plus as much as you need to store content. 5GB is probably a realistic minimum.
* Processor: 1GHz (min), 2GHz dual core or more recommended.
* Memory: 512MB (min), 1GB or more is recommended. 8GB plus is likely on a large production server
* Consider separate servers for the web "front ends" and the database. It is much easier to "tune"

All the above requirements will vary depending on specific hardware and software combinations as well as the type of use and load; busy sites may well require additional resources. Further guidance can be found under [[Performance_recommendations|performance recommendations]]. Moodle scales easily by increasing hardware.

For very large sites, you are much better starting with a small pilot and gaining some experience and insight. A "what hardware do I need for 50,000 user?" style post in the forums is highly unlikely to get a useful answer.

=== Software ===

See the [{{Release notes}} release notes] in the dev docs for software requirements.

== Set up your server ==

Depending the use case a Moodle server may be anything from a Desktop PC (e.g. for testing and evaluating) to a rackmounted or [[Server cluster|clustered]] solution. As mentioned above there are lots of possibilities for installing the basic server software, some links and pointers are at [[Installing AMP]], [[Internet_Information_Services|IIS]], [[Nginx]].

It will help hugely, regardless of your deployment choices, if time is taken to understand how to configure the different parts of your software stack (HTTP daemon, database, PHP etc). Do not expect the standard server configuration to be optimal for Moodle. For example, the web server and database servers will almost certainly require tuning to get the best out of Moodle.

If a hosting provider is being used ensure that all Moodle [{{Release notes}}#Server_requirements requirements] (such as PHP version) are met by the hosting platform before attempting the installation. It will help to become familiar with changing settings within the hosting provider's platform (e.g. PHP file upload maximums) as the options and tools provided vary.

== Download and copy files into place ==

'''IMPORTANT: While there are now a number of places you can get the Moodle code (including host provided Moodle installers), you are strongly advised to only obtain Moodle from moodle.org. If you run into problems it will be a great deal easier to support you.'''

You have two options:
* Download your required version from http://moodle.org/downloads and unzip/unpack...
* '''OR''' Pull the code from the Git repository (recommended for developers and also makes upgrading very simple):
<pre>
$ git clone -b MOODLE_{{Version3}}_STABLE git://git.moodle.org/moodle.git
</pre>

Other options you might consider:

* ''--depth=1'' for shallow cloning (only) latest revision (be advised! If you are a developer, you will not be able to easily make git updates and modification later on when this feature is used)

* ''--single-branch'' to limit cloning to a single branch, this fetches the Moodle {{Version}} Stable branch (latest weekly build). For a fuller discussion see [[Git for Administrators]].

Either of the above should result in a directory called '''moodle''', containing a number of files and folders.

You can typically place the whole folder in your web server documents directory, in which case the site will be located at '''<nowiki>http://yourwebserver.com/moodle</nowiki>''', or you can copy all the contents straight into the main web server documents directory, in which case the site will be simply '''<nowiki>http://yourwebserver.com</nowiki>'''. See the documentation for your system and/or web server if you are unsure.

:''Tip:'' If you are downloading Moodle to your local computer and then uploading it to your hosted web site, if possible upload the compressed file and decompress at the remote end (check your 'file manager'). Failing that, watch FTP progress carefully for errors or missed files.

* '''Secure the Moodle files:''' It is vital that the files are not writeable by the web server user. For example, on Unix/Linux (as root):
<pre>
# chown -R root /path/to/moodle
# chmod -R 0755 /path/to/moodle
# find /path/to/moodle -type f -exec chmod 0644 {} \;
</pre>
(files are owned by the administrator/superuser and are only writeable by them - readable by everyone else)

The third command finds all the regular files and executes the chmod command 0644 on them.

If you want to use the built-in plugin installer you need to make the directory writable by web server user. It is strongly recommended to use ACL when your server supports it, for example if your Apache server uses account www-data:

<pre>
# chmod -R +a "www-data allow read,delete,write,append,file_inherit,directory_inherit" /path/to/moodle
</pre>

The effect of the previous command is to allow the Apache user account (www-data in this case) to access and change files within the moodle site. Many people would consider this a brave move for a new site admin to implement. In a new moodle you can safely leave this out. A default Ubuntu install does not have the +a option for the chmod command anyway. The +a attribute is an ACL (Access Control List) facility which allows you to set per user access for individual files. For example, OSX has this by default.

== Create an empty database ==

Next create a new, empty database for your installation. You need to find and make a note of following information for use during the final installation stage:
* '''dbhost''' - the database server hostname. Probably ''localhost'' if the database and web server are the same machine, otherwise the name of the database server
* '''dbname''' - the database name. Whatever you called it, e.g. ''moodle''
* '''dbuser''' - the username for the database. Whatever you assigned, e.g. ''moodleuser'' - do not use the root/superuser account. Create a proper account with the minimum permissions needed.
* '''dbpass''' - the password for the above user

If your site is hosted you should find a web-based administration page for databases as part of the control panel (or ask your administrator). For everyone else or for detailed instructions, see the page for your chosen database server:
* [[PostgreSQL]] (recommended)
* [[MariaDB]] (recommended)
* [[MySQL]]
* [[MSSQL]]
* [[Oracle]] (not recommended)

== Create the (''moodledata'') data directory ==

Moodle requires a directory to store all of its files (all your site's uploaded files, temporary data, cache, session data etc.). The web server needs to be able to write to this directory. On larger systems consider how much free space you are going to use when allocating this directory.

Due to the default way Moodle caches data you may have serious performance issues if you use relatively slow storage (e.g. NFS) for this directory. Read the [[Performance_recommendations]] carefully and consider using (e.g.) redis or memcached for [[Caching]].

'''IMPORTANT:''' This directory must '''NOT''' be accessible directly via the web. This would be a serious security hole. Do not try to place it inside your web root or inside your Moodle program files directory. Moodle will not install. It can go anywhere else convenient.

Here is an example (Unix/Linux) of creating the directory and setting the permissions for '''anyone''' on the server to write here. This is only appropriate for Moodle servers that are not shared. Discuss this with your server administrator for better permissions that just allow the web server user to access these files.

<pre>
# mkdir /path/to/moodledata
# chmod 0777 /path/to/moodledata
</pre>

==== Securing moodledata in a web directory ====

If you are using a hosted site and you have no option but to place 'moodledata' in a web accessible directory. You may be able to secure it by creating an .htaccess file in the 'moodledata' directory. This does not work on all systems - see your host/administrator. Create a file called .htaccess containing only the following lines:
<pre>
order deny,allow
deny from all
</pre>

== Start Moodle install ==
It's now time to run the installer to create the database tables and configure your new site. The recommended method is to use the command line installer. If you cannot do this for any reason (e.g. on a Windows server) the web-based installer is still available.

=== Command line installer ===

It's best to run the command line as your system's web user. You need to know what that is - see your system's documentation (e.g. Ubuntu/Debian is 'www-data', Centos is 'apache')

* Example of using the command-line (as root - substitute 'www-data' for your web user):
<pre>
# chown www-data /path/to/moodle
# cd /path/to/moodle/admin/cli
# sudo -u www-data /usr/bin/php install.php
# chown -R root /path/to/moodle
</pre>
The chowns allow the script to write a new config.php file. More information about the options can be found using
<pre>
# php install.php --help
</pre>

You will be asked for other settings that have not been discussed on this page - if unsure just accept the defaults. For a full discussion see [[Administration via command line]]

=== Web based installer ===

For ease of use you can install Moodle via the web. We recommend configuring your web server so that the page is not publicly accessible until the installation is complete.

To run the web installer script, just go to your Moodle's main URL using a web browser.

The installation process will take you through a number of pages. You should be asked to confirm the copyright, see the database tables being created, supply administrator account details and supply the site details. The database creation can take some time - please be patient. You should eventually end up at the Moodle front page with an invitation to create a new course.

It is very likely that you will be asked to download the new config.php file and upload it to your Moodle installation - just follow the on-screen instructions.

==Final configuration==

=== Settings within Moodle ===
There are a number of options within the Moodle Site Administration screens (accessible from the 'Site administration' tab in the 'Administration' block (Classic theme) or the Site administration button in the navigation bar (Boost). Here are a few of the more important ones that you will probably want to check:
* ''Administration > Site administration > Server > Email > Outgoing mail configuration'': Set your smtp server and authentication if required (so your Moodle site can send emails). You can also set a norepy email on this page.
* ''Administration > Site administration > Server > Server > Support contact''. Set your support contact email.
* ''Administration > Site administration > Server > System paths'': Set the paths to du, dot and aspell binaries.
* ''Administration > Site administration > Server > HTTP'': If you are behind a firewall you may need to set your proxy credentials in the 'Web proxy' section.
* ''Administration > Site administration > Location > Update timezones'': Run this to make sure your timezone information is up to date. (more info [[Location]])
** [http://php.net/manual/en/timezones.php Set server's local timezone] inside <tt>php.ini</tt> (should probably be inside <tt>/etc/php.ini</tt> or <tt>/etc/php.d/date.ini</tt>, depending on the underlying OS):
<code php>
[Date]
; Defines the default timezone used by the date functions
date.timezone = "YOUR LOCAL TIMEZONE"
</code>

=== Remaining tasks ===

* '''Configure Cron''': Moodle's background tasks (e.g. sending out forum emails and performing course backups) are performed by a script which you can set to execute at specific times of the day. This is known as a cron script. Please refer to the [[Cron|Cron instructions]].
* '''Set up backups''': See [[Site backup]] and [[Automated course backup]].
* '''Secure your Moodle site''': Read the [[Security recommendations]].
*'''Increasing the maximum upload size''' See [[Installation FAQ]] Maximum upload file size - how to change it?
* '''Check mail works''' : From Site administration > Server > Test outgoing mail configuration, use the link to send yourself a test email. Don't be tempted to skip this step.

=== Installation is complete :) ===

* Create a new course: You can now access Moodle through your web browser (using the same URL as you set during the install process), log in as your admin user and creatse a new course. See [[Adding a new course|create a new course]].

=== If something goes wrong... ===

Here are some things you should try...

* Check the [[Installation FAQ]]
* Check your file permissions carefully. Can your web server read (but not write) the Moodle program files? Can your web server read and write your Moodle data directory? If you don't fully understand how file ownership and permissions work on your operating system it would be time very well spent to find out.
* Check your database permissions. Have you set up your database user with the correct rights and permissions for your configuration (especially if the web server and database server are different machines)?
* Create your [[Configuration file]] (config.php) by hand. Copy config-dist.php (in the root of the Moodle program directory) to config.php, edit it and set your database/site options there. Installation will continue from the right place.
* Once you have a config.php (see previous tip) you can edit it to turn on debugging (in section 8). This may give you extra information to help track down a problem. If you have access, check your web server error log(s).
* Re-check your php.ini / .htaccess settings. Are they appropriate (e.g. memory_limit), did you edit the correct php.ini / .htaccess file and (if required) did you re-start the web server after making changes?
* Did you include any non-core (optional) plugins, themes or other code before starting the installation script? If so, remove it and try again (it may be broken or incompatible).
* Explain your problem in the [http://moodle.org/mod/forum/view.php?id=28 Installation problems forum]. '''PLEASE''' list your software versions; explain what you did, what happened and what error messages you saw (if any); explain what you tried. There is no such thing as 'nothing', even a blank page is something!

== Platform specific instructions ==

'''Note:''' Much of this information is provided by the community. It may not have been checked and may be out of date. Please read in conjunction with the above installation instructions.

* [[Windows installation]]
** [[Installing Moodle on SmarterASP.NET]]
* [[Unix or Linux Installation]]
* [[Mac Installation]]
* [[Amazon EC2 Cloud Services Installation]]

== See also ==
* [http://www.slideshare.net/gb2048/my-own-moodle Slideshare presentation by Gareth Barnard on installing a local installation of Moodle] and accompanying [https://drive.google.com/folderview?id=0B17B0rYH2zERU21sQnVweUZCUFk&usp=sharing help guides]
* [http://moodle.org/mod/forum/discuss.php?d=182086 New Video Tutorial- How to Install Moodle on Shared Hosting via cPanel (Not Fantastico)]
* [http://moodle.org/mod/forum/discuss.php?d=199542 Video Tutorial - Install Moodle on a Virtual Box from scratch]

[[es:Instalaci%C3%B3n_de_moodle]]
[[de:Installation von Moodle]]
[[fr:Installation de Moodle]]
[[ja:Moodleのインストール]]

Upgrading

2020-03-11T09:36:20Z

Howardsmiller: /* Install the new Moodle software */

{{Installing Moodle}}
''This page explains in detail how to upgrade Moodle. For a summary of the process, see [[Upgrade overview]].''

==Check the requirements==

Before upgrading, check that your server meets all requirements for {{Version}} in ''Site administration > Server > [[Environment]]''.

See the [{{Release notes}} release notes] in the dev docs for both [{{Release notes}}#Server_requirements server] and [{{Release notes}}#Client_requirements client] software requirements.

Notes:

* You can only upgrade to Moodle {{Version}} from Moodle 3.2 or later. If upgrading from earlier versions, you must [https://docs.moodle.org/32/en/Upgrading_to_Moodle_3.2 upgrade to 3.2] as a first step.

==Before upgrading==

'''We advise that you test the upgrade first on a COPY of your production site, to make sure it works as you expect.'''

Consider setting the [[Upgrade key|upgrade key]] for your site.

== Backup important data ==

There are three areas that should be backed up before any upgrade:
#Moodle software (For example, everything in server/htdocs/moodle)
#Moodle uploaded files (For example, server/moodledata)
#Moodle database (For example, your Postgres or MySQL database dump)

See [[Site backup]] for more specific information.

== Check for plugin updates ==

If you have [[Automatic updates deployment]] enabled, you will be able to update installed plugins automatically during the upgrade. Just make sure you check for available updates (via the button for it) at the Plugins check screen.

If you are updating plugins manually, it is a good moment now to check in the [http://moodle.org/plugins Moodle Plugins directory] whether there is a {{Version}} version available for any plugins (including themes) that you have previously installed on your site. If so, download the plugin package. In the next step, you will copy it to the appropriate location in your Moodle code (see [[Installing plugins]]).

The upgrade of the plugin will then happen as part of the Moodle upgrade process.

If an out-of-date plugin causes your upgrade to fail, you can usually delete the plugin code rather than uninstalling it from within Moodle so that the data associated with it is not deleted.

==Put your site into maintenance mode==
Before you begin upgrading your site, you should put it into [[Maintenance_mode | maintenance mode]] to stop any non-admin users from logging in. Then you should wait for any currently running cron processes to complete before proceeding.

== Install the new Moodle software ==
You can fetch the current version of the software at

wget http://sourceforge.net/projects/moodle/files/Moodle/stable38/moodle-latest-38.tgz

=== Standard install package ===

# Move your old Moodle software program files to another location. ''Do NOT copy new files over the old files.''
# Unzip or unpack the upgrade file so that all the new Moodle software program files are in the location the old files used to be in on the server. Moodle will adjust SQL and moodledata if it needs to in the upgrade.
# Copy your old [[Configuration file|config.php file]] back to the new Moodle directory.
# As mentioned above, if you had installed any plugins on your site you should add them to the new code tree (Moodle directory structure) now. It is important to check that you get the correct version for your new version of Moodle. Be particularly careful that you do not overwrite any code in the new version of Moodle and that you place the plugin folders in the correct directory (the same directory that they are in in the current installation.)
# Your moodledata folder should be located separately to your Moodle code folder and, as such, should not need anything done to it. Moodle 3.0 will throw a warning if it is located in a web accessible folder and the moodledata should never be located in the Moodle code folder. If you are moving your installation to a new server or new location on your server, then you will need to follow the [[Migration]] documents.

====Linux====
mv moodle moodle.backup
tar xvzf moodle-latest-{{Version}}.tgz

Next, copy across your config.php, any custom plugins, and your .htaccess file if you created one ('''check that custom plugins are the correct version for your new Moodle first'''):

cp moodle.backup/config.php moodle
cp -pr moodle.backup/theme/mytheme moodle/theme/mytheme
cp -pr moodle.backup/mod/mymod moodle/mod/mymod

Don't forget to make moodle/config.php (and the rest of the source code) readable by your www server. For maximum security the files should not be writeable by your server. This is especially important on a 'production' server open to the public internet.

chown -R root:root moodle (Linux debian - or even create a user especially for moodle. '''Don't''' use the web server user, e.g. www-data)
chmod -R 755 moodle

If you use cron, take care that cron.php is executeable and uses the correct php command:
chmod 740 admin/cli/cron.php (some configurations need chmod 750 or chmod 755)
copy the first line from cron.php (if it looks like '#!/usr/local/bin/php' or '#!/usr/local/bin/php5.3', no need to copy '<?php')
if necessary. However, for a simple upgrade, there should be no need to change anything with cron.

=== Using Git ===

You can use Git for updating or upgrading your Moodle. See [[Git for Administrators]] for details.

===Command line upgrade===

On Linux servers, Moodle {{Version}} supports running the [[CLI|upgrade from the command line]], rather than through a web browser. This is likely to be more reliable, particularly for large sites.

== Finishing the upgrade ==

The last step is to trigger the upgrade processes within Moodle.

If you put your site into Maintenance mode earlier; take it out now!

To do this just go to ''Site administration > Notifications''.

Moodle will automatically detect the new version and perform all the SQL database or file system upgrades that are necessary. If there is anything it can't do itself (very rare) then you will see messages telling you what you need to do.

Assuming all goes well (no error messages) then you can start using your new version of Moodle and enjoy the new features!

Note: If you are running multiple servers then you should purge all caches manually (via ''Site administration > Development > Purge all caches'') after completing the upgrade on all servers.

===Fatal error: Maximum execution time of 30 seconds exceeded...===

If your server uses a main language other than English, you may encounter a 'Fatal error: Maximum execution time of 30 seconds exceeded' when you try to upgrade it. You can increase max_execution_time = 160 on php.ini to allow the scripts enough time to process the language update. Otherwise, you can switch to English as the default language before doing the upgrade and back to your original language after a successful upgrade. See the forum discussion at https://moodle.org/mod/forum/discuss.php?d=119598.

==After upgrading==

==Possible issues that may affect you in Moodle {{Version}}==

===Course overview improvements===

New course overview settings enable an admin to

* reduce the currently available layouts (Card, List and Summary)
* specify which filter options are available, including providing a custom filter which uses course custom field values

===Course request changes===

The capabilities moodle/course:request and moodle/site:approvecourse may now be applied in the category context.

===Removed functionality===

* The Community finder block and course-sharing functionality have been removed as part of the preparations for the new MoodleNet open social media platform.
* The People block has been removed because there is a Participants link in the navigation drawer (Boost theme) and in the navigation block (Classic theme).

''Please add more items here...''

See also the list of [https://tracker.moodle.org/issues/?jql=project%20%3D%20mdl%20AND%20resolution%20%3D%20fixed%20AND%20fixVersion%20in%20(%223.8%22)%20AND%20labels%20%3D%20upgrade_notes upgrade_notes-labelled issues] and [https://tracker.moodle.org/issues/?jql=project%20%3D%20mdl%20AND%20resolution%20%3D%20fixed%20AND%20fixVersion%20in%20(%223.8%22)%20AND%20labels%20%3D%20ui_change%20 ui_change-labelled issues].

===New capabilities in Moodle {{Version}}===

'''Forum'''

* forumreport/summary:view
* forumreport/summary:viewall
* mod/forum:exportforum
* mod/forum:grade

'''H5P'''

* atto/h5p:addembed
* moodle/h5p:deploy
* moodle/h5p:setdisplayoptions
* moodle/h5p:updatelibraries

=== Moodle 3.2, 3.3, 3.4, 3.5, 3.6 and 3.7 improvements ===

Depending on which version you are upgrading from, please see the section 'Possible issues that may affect you' in the documentation

* [https://docs.moodle.org/32/en/Upgrading Upgrading to Moodle 3.2]
* [https://docs.moodle.org/33/en/Upgrading Upgrading to Moodle 3.3]
* [https://docs.moodle.org/34/en/Upgrading Upgrading to Moodle 3.4]
* [https://docs.moodle.org/35/en/Upgrading Upgrading to Moodle 3.5]
* [https://docs.moodle.org/36/en/Upgrading Upgrading to Moodle 3.6]
* [https://docs.moodle.org/37/en/Upgrading Upgrading to Moodle 3.7]

==Any questions about the process?==

Please post in the [https://moodle.org/mod/forum/view.php?id=28 Installing and upgrading help forum] on moodle.org.

==See also==

* [[dev:Moodle {{Version}} release notes|Moodle {{Version}} release notes]]
* [https://moodle.org/mod/forum/discuss.php?d=393570 Problem accessing dropdown such as personal profile since 3.8 (20191118) update] forum discussion

[[es:Actualización de moodle]]
[[fr:Mise à jour]]
[[ja:Moodleをアップグレードする]]
[[de:Aktualisierung von Moodle]]

Upgrading

2020-03-11T09:34:49Z

Howardsmiller: Undo revision 136720 by Howardsmiller (talk)

{{Installing Moodle}}
''This page explains in detail how to upgrade Moodle. For a summary of the process, see [[Upgrade overview]].''

==Check the requirements==

Before upgrading, check that your server meets all requirements for {{Version}} in ''Site administration > Server > [[Environment]]''.

See the [{{Release notes}} release notes] in the dev docs for both [{{Release notes}}#Server_requirements server] and [{{Release notes}}#Client_requirements client] software requirements.

Notes:

* You can only upgrade to Moodle {{Version}} from Moodle 3.2 or later. If upgrading from earlier versions, you must [https://docs.moodle.org/32/en/Upgrading_to_Moodle_3.2 upgrade to 3.2] as a first step.

==Before upgrading==

'''We advise that you test the upgrade first on a COPY of your production site, to make sure it works as you expect.'''

Consider setting the [[Upgrade key|upgrade key]] for your site.

== Backup important data ==

There are three areas that should be backed up before any upgrade:
#Moodle software (For example, everything in server/htdocs/moodle)
#Moodle uploaded files (For example, server/moodledata)
#Moodle database (For example, your Postgres or MySQL database dump)

See [[Site backup]] for more specific information.

== Check for plugin updates ==

If you have [[Automatic updates deployment]] enabled, you will be able to update installed plugins automatically during the upgrade. Just make sure you check for available updates (via the button for it) at the Plugins check screen.

If you are updating plugins manually, it is a good moment now to check in the [http://moodle.org/plugins Moodle Plugins directory] whether there is a {{Version}} version available for any plugins (including themes) that you have previously installed on your site. If so, download the plugin package. In the next step, you will copy it to the appropriate location in your Moodle code (see [[Installing plugins]]).

The upgrade of the plugin will then happen as part of the Moodle upgrade process.

If an out-of-date plugin causes your upgrade to fail, you can usually delete the plugin code rather than uninstalling it from within Moodle so that the data associated with it is not deleted.

==Put your site into maintenance mode==
Before you begin upgrading your site, you should put it into [[Maintenance_mode | maintenance mode]] to stop any non-admin users from logging in. Then you should wait for any currently running cron processes to complete before proceeding.

== Install the new Moodle software ==
You can fetch the current version of the software at

wget https://download.moodle.org/download.php/stable38/moodle-3.8.2.zip

=== Standard install package ===

# Move your old Moodle software program files to another location. ''Do NOT copy new files over the old files.''
# Unzip or unpack the upgrade file so that all the new Moodle software program files are in the location the old files used to be in on the server. Moodle will adjust SQL and moodledata if it needs to in the upgrade.
# Copy your old [[Configuration file|config.php file]] back to the new Moodle directory.
# As mentioned above, if you had installed any plugins on your site you should add them to the new code tree (Moodle directory structure) now. It is important to check that you get the correct version for your new version of Moodle. Be particularly careful that you do not overwrite any code in the new version of Moodle and that you place the plugin folders in the correct directory (the same directory that they are in in the current installation.)
# Your moodledata folder should be located separately to your Moodle code folder and, as such, should not need anything done to it. Moodle 3.0 will throw a warning if it is located in a web accessible folder and the moodledata should never be located in the Moodle code folder. If you are moving your installation to a new server or new location on your server, then you will need to follow the [[Migration]] documents.

====Linux====
mv moodle moodle.backup
tar xvzf moodle-latest-{{Version}}.tgz

Next, copy across your config.php, any custom plugins, and your .htaccess file if you created one ('''check that custom plugins are the correct version for your new Moodle first'''):

cp moodle.backup/config.php moodle
cp -pr moodle.backup/theme/mytheme moodle/theme/mytheme
cp -pr moodle.backup/mod/mymod moodle/mod/mymod

Don't forget to make moodle/config.php (and the rest of the source code) readable by your www server. For maximum security the files should not be writeable by your server. This is especially important on a 'production' server open to the public internet.

chown -R root:root moodle (Linux debian - or even create a user especially for moodle. '''Don't''' use the web server user, e.g. www-data)
chmod -R 755 moodle

If you use cron, take care that cron.php is executeable and uses the correct php command:
chmod 740 admin/cli/cron.php (some configurations need chmod 750 or chmod 755)
copy the first line from cron.php (if it looks like '#!/usr/local/bin/php' or '#!/usr/local/bin/php5.3', no need to copy '<?php')
if necessary. However, for a simple upgrade, there should be no need to change anything with cron.

=== Using Git ===

You can use Git for updating or upgrading your Moodle. See [[Git for Administrators]] for details.

===Command line upgrade===

On Linux servers, Moodle {{Version}} supports running the [[CLI|upgrade from the command line]], rather than through a web browser. This is likely to be more reliable, particularly for large sites.

== Finishing the upgrade ==

The last step is to trigger the upgrade processes within Moodle.

If you put your site into Maintenance mode earlier; take it out now!

To do this just go to ''Site administration > Notifications''.

Moodle will automatically detect the new version and perform all the SQL database or file system upgrades that are necessary. If there is anything it can't do itself (very rare) then you will see messages telling you what you need to do.

Assuming all goes well (no error messages) then you can start using your new version of Moodle and enjoy the new features!

Note: If you are running multiple servers then you should purge all caches manually (via ''Site administration > Development > Purge all caches'') after completing the upgrade on all servers.

===Fatal error: Maximum execution time of 30 seconds exceeded...===

If your server uses a main language other than English, you may encounter a 'Fatal error: Maximum execution time of 30 seconds exceeded' when you try to upgrade it. You can increase max_execution_time = 160 on php.ini to allow the scripts enough time to process the language update. Otherwise, you can switch to English as the default language before doing the upgrade and back to your original language after a successful upgrade. See the forum discussion at https://moodle.org/mod/forum/discuss.php?d=119598.

==After upgrading==

==Possible issues that may affect you in Moodle {{Version}}==

===Course overview improvements===

New course overview settings enable an admin to

* reduce the currently available layouts (Card, List and Summary)
* specify which filter options are available, including providing a custom filter which uses course custom field values

===Course request changes===

The capabilities moodle/course:request and moodle/site:approvecourse may now be applied in the category context.

===Removed functionality===

* The Community finder block and course-sharing functionality have been removed as part of the preparations for the new MoodleNet open social media platform.
* The People block has been removed because there is a Participants link in the navigation drawer (Boost theme) and in the navigation block (Classic theme).

''Please add more items here...''

See also the list of [https://tracker.moodle.org/issues/?jql=project%20%3D%20mdl%20AND%20resolution%20%3D%20fixed%20AND%20fixVersion%20in%20(%223.8%22)%20AND%20labels%20%3D%20upgrade_notes upgrade_notes-labelled issues] and [https://tracker.moodle.org/issues/?jql=project%20%3D%20mdl%20AND%20resolution%20%3D%20fixed%20AND%20fixVersion%20in%20(%223.8%22)%20AND%20labels%20%3D%20ui_change%20 ui_change-labelled issues].

===New capabilities in Moodle {{Version}}===

'''Forum'''

* forumreport/summary:view
* forumreport/summary:viewall
* mod/forum:exportforum
* mod/forum:grade

'''H5P'''

* atto/h5p:addembed
* moodle/h5p:deploy
* moodle/h5p:setdisplayoptions
* moodle/h5p:updatelibraries

=== Moodle 3.2, 3.3, 3.4, 3.5, 3.6 and 3.7 improvements ===

Depending on which version you are upgrading from, please see the section 'Possible issues that may affect you' in the documentation

* [https://docs.moodle.org/32/en/Upgrading Upgrading to Moodle 3.2]
* [https://docs.moodle.org/33/en/Upgrading Upgrading to Moodle 3.3]
* [https://docs.moodle.org/34/en/Upgrading Upgrading to Moodle 3.4]
* [https://docs.moodle.org/35/en/Upgrading Upgrading to Moodle 3.5]
* [https://docs.moodle.org/36/en/Upgrading Upgrading to Moodle 3.6]
* [https://docs.moodle.org/37/en/Upgrading Upgrading to Moodle 3.7]

==Any questions about the process?==

Please post in the [https://moodle.org/mod/forum/view.php?id=28 Installing and upgrading help forum] on moodle.org.

==See also==

* [[dev:Moodle {{Version}} release notes|Moodle {{Version}} release notes]]
* [https://moodle.org/mod/forum/discuss.php?d=393570 Problem accessing dropdown such as personal profile since 3.8 (20191118) update] forum discussion

[[es:Actualización de moodle]]
[[fr:Mise à jour]]
[[ja:Moodleをアップグレードする]]
[[de:Aktualisierung von Moodle]]

Upgrading

2020-03-10T12:43:20Z

Howardsmiller: /* Install the new Moodle software */

{{Installing Moodle}}
''This page explains in detail how to upgrade Moodle. For a summary of the process, see [[Upgrade overview]].''

==Check the requirements==

Before upgrading, check that your server meets all requirements for {{Version}} in ''Site administration > Server > [[Environment]]''.

See the [{{Release notes}} release notes] in the dev docs for both [{{Release notes}}#Server_requirements server] and [{{Release notes}}#Client_requirements client] software requirements.

Notes:

* You can only upgrade to Moodle {{Version}} from Moodle 3.2 or later. If upgrading from earlier versions, you must [https://docs.moodle.org/32/en/Upgrading_to_Moodle_3.2 upgrade to 3.2] as a first step.

==Before upgrading==

'''We advise that you test the upgrade first on a COPY of your production site, to make sure it works as you expect.'''

Consider setting the [[Upgrade key|upgrade key]] for your site.

== Backup important data ==

There are three areas that should be backed up before any upgrade:
#Moodle software (For example, everything in server/htdocs/moodle)
#Moodle uploaded files (For example, server/moodledata)
#Moodle database (For example, your Postgres or MySQL database dump)

See [[Site backup]] for more specific information.

== Check for plugin updates ==

If you have [[Automatic updates deployment]] enabled, you will be able to update installed plugins automatically during the upgrade. Just make sure you check for available updates (via the button for it) at the Plugins check screen.

If you are updating plugins manually, it is a good moment now to check in the [http://moodle.org/plugins Moodle Plugins directory] whether there is a {{Version}} version available for any plugins (including themes) that you have previously installed on your site. If so, download the plugin package. In the next step, you will copy it to the appropriate location in your Moodle code (see [[Installing plugins]]).

The upgrade of the plugin will then happen as part of the Moodle upgrade process.

If an out-of-date plugin causes your upgrade to fail, you can usually delete the plugin code rather than uninstalling it from within Moodle so that the data associated with it is not deleted.

==Put your site into maintenance mode==
Before you begin upgrading your site, you should put it into [[Maintenance_mode | maintenance mode]] to stop any non-admin users from logging in. Then you should wait for any currently running cron processes to complete before proceeding.

== Install the new Moodle software ==
You can fetch the current, stable version of the software at

wget https://download.moodle.org/download.php/stable38/moodle-3.8.2.zip

...or the latest weekly build here...

wget https://github.com/moodle/moodle/archive/MOODLE_38_STABLE.zip

=== Standard install package ===

# Move your old Moodle software program files to another location. ''Do NOT copy new files over the old files.''
# Unzip or unpack the upgrade file so that all the new Moodle software program files are in the location the old files used to be in on the server. Moodle will adjust SQL and moodledata if it needs to in the upgrade.
# Copy your old [[Configuration file|config.php file]] back to the new Moodle directory.
# As mentioned above, if you had installed any plugins on your site you should add them to the new code tree (Moodle directory structure) now. It is important to check that you get the correct version for your new version of Moodle. Be particularly careful that you do not overwrite any code in the new version of Moodle and that you place the plugin folders in the correct directory (the same directory that they are in in the current installation.)
# Your moodledata folder should be located separately to your Moodle code folder and, as such, should not need anything done to it. Moodle 3.0 will throw a warning if it is located in a web accessible folder and the moodledata should never be located in the Moodle code folder. If you are moving your installation to a new server or new location on your server, then you will need to follow the [[Migration]] documents.

====Linux====
mv moodle moodle.backup
tar xvzf moodle-latest-{{Version}}.tgz

Next, copy across your config.php, any custom plugins, and your .htaccess file if you created one ('''check that custom plugins are the correct version for your new Moodle first'''):

cp moodle.backup/config.php moodle
cp -pr moodle.backup/theme/mytheme moodle/theme/mytheme
cp -pr moodle.backup/mod/mymod moodle/mod/mymod

Don't forget to make moodle/config.php (and the rest of the source code) readable by your www server. For maximum security the files should not be writeable by your server. This is especially important on a 'production' server open to the public internet.

chown -R root:root moodle (Linux debian - or even create a user especially for moodle. '''Don't''' use the web server user, e.g. www-data)
chmod -R 755 moodle

If you use cron, take care that cron.php is executeable and uses the correct php command:
chmod 740 admin/cli/cron.php (some configurations need chmod 750 or chmod 755)
copy the first line from cron.php (if it looks like '#!/usr/local/bin/php' or '#!/usr/local/bin/php5.3', no need to copy '<?php')
if necessary. However, for a simple upgrade, there should be no need to change anything with cron.

=== Using Git ===

You can use Git for updating or upgrading your Moodle. See [[Git for Administrators]] for details.

===Command line upgrade===

On Linux servers, Moodle {{Version}} supports running the [[CLI|upgrade from the command line]], rather than through a web browser. This is likely to be more reliable, particularly for large sites.

== Finishing the upgrade ==

The last step is to trigger the upgrade processes within Moodle.

If you put your site into Maintenance mode earlier; take it out now!

To do this just go to ''Site administration > Notifications''.

Moodle will automatically detect the new version and perform all the SQL database or file system upgrades that are necessary. If there is anything it can't do itself (very rare) then you will see messages telling you what you need to do.

Assuming all goes well (no error messages) then you can start using your new version of Moodle and enjoy the new features!

Note: If you are running multiple servers then you should purge all caches manually (via ''Site administration > Development > Purge all caches'') after completing the upgrade on all servers.

===Fatal error: Maximum execution time of 30 seconds exceeded...===

If your server uses a main language other than English, you may encounter a 'Fatal error: Maximum execution time of 30 seconds exceeded' when you try to upgrade it. You can increase max_execution_time = 160 on php.ini to allow the scripts enough time to process the language update. Otherwise, you can switch to English as the default language before doing the upgrade and back to your original language after a successful upgrade. See the forum discussion at https://moodle.org/mod/forum/discuss.php?d=119598.

==After upgrading==

==Possible issues that may affect you in Moodle {{Version}}==

===Course overview improvements===

New course overview settings enable an admin to

* reduce the currently available layouts (Card, List and Summary)
* specify which filter options are available, including providing a custom filter which uses course custom field values

===Course request changes===

The capabilities moodle/course:request and moodle/site:approvecourse may now be applied in the category context.

===Removed functionality===

* The Community finder block and course-sharing functionality have been removed as part of the preparations for the new MoodleNet open social media platform.
* The People block has been removed because there is a Participants link in the navigation drawer (Boost theme) and in the navigation block (Classic theme).

''Please add more items here...''

See also the list of [https://tracker.moodle.org/issues/?jql=project%20%3D%20mdl%20AND%20resolution%20%3D%20fixed%20AND%20fixVersion%20in%20(%223.8%22)%20AND%20labels%20%3D%20upgrade_notes upgrade_notes-labelled issues] and [https://tracker.moodle.org/issues/?jql=project%20%3D%20mdl%20AND%20resolution%20%3D%20fixed%20AND%20fixVersion%20in%20(%223.8%22)%20AND%20labels%20%3D%20ui_change%20 ui_change-labelled issues].

===New capabilities in Moodle {{Version}}===

'''Forum'''

* forumreport/summary:view
* forumreport/summary:viewall
* mod/forum:exportforum
* mod/forum:grade

'''H5P'''

* atto/h5p:addembed
* moodle/h5p:deploy
* moodle/h5p:setdisplayoptions
* moodle/h5p:updatelibraries

=== Moodle 3.2, 3.3, 3.4, 3.5, 3.6 and 3.7 improvements ===

Depending on which version you are upgrading from, please see the section 'Possible issues that may affect you' in the documentation

* [https://docs.moodle.org/32/en/Upgrading Upgrading to Moodle 3.2]
* [https://docs.moodle.org/33/en/Upgrading Upgrading to Moodle 3.3]
* [https://docs.moodle.org/34/en/Upgrading Upgrading to Moodle 3.4]
* [https://docs.moodle.org/35/en/Upgrading Upgrading to Moodle 3.5]
* [https://docs.moodle.org/36/en/Upgrading Upgrading to Moodle 3.6]
* [https://docs.moodle.org/37/en/Upgrading Upgrading to Moodle 3.7]

==Any questions about the process?==

Please post in the [https://moodle.org/mod/forum/view.php?id=28 Installing and upgrading help forum] on moodle.org.

==See also==

* [[dev:Moodle {{Version}} release notes|Moodle {{Version}} release notes]]
* [https://moodle.org/mod/forum/discuss.php?d=393570 Problem accessing dropdown such as personal profile since 3.8 (20191118) update] forum discussion

[[es:Actualización de moodle]]
[[fr:Mise à jour]]
[[ja:Moodleをアップグレードする]]
[[de:Aktualisierung von Moodle]]

Upgrading

2020-03-10T12:41:24Z

Howardsmiller: /* Install the new Moodle software */

{{Installing Moodle}}
''This page explains in detail how to upgrade Moodle. For a summary of the process, see [[Upgrade overview]].''

==Check the requirements==

Before upgrading, check that your server meets all requirements for {{Version}} in ''Site administration > Server > [[Environment]]''.

See the [{{Release notes}} release notes] in the dev docs for both [{{Release notes}}#Server_requirements server] and [{{Release notes}}#Client_requirements client] software requirements.

Notes:

* You can only upgrade to Moodle {{Version}} from Moodle 3.2 or later. If upgrading from earlier versions, you must [https://docs.moodle.org/32/en/Upgrading_to_Moodle_3.2 upgrade to 3.2] as a first step.

==Before upgrading==

'''We advise that you test the upgrade first on a COPY of your production site, to make sure it works as you expect.'''

Consider setting the [[Upgrade key|upgrade key]] for your site.

== Backup important data ==

There are three areas that should be backed up before any upgrade:
#Moodle software (For example, everything in server/htdocs/moodle)
#Moodle uploaded files (For example, server/moodledata)
#Moodle database (For example, your Postgres or MySQL database dump)

See [[Site backup]] for more specific information.

== Check for plugin updates ==

If you have [[Automatic updates deployment]] enabled, you will be able to update installed plugins automatically during the upgrade. Just make sure you check for available updates (via the button for it) at the Plugins check screen.

If you are updating plugins manually, it is a good moment now to check in the [http://moodle.org/plugins Moodle Plugins directory] whether there is a {{Version}} version available for any plugins (including themes) that you have previously installed on your site. If so, download the plugin package. In the next step, you will copy it to the appropriate location in your Moodle code (see [[Installing plugins]]).

The upgrade of the plugin will then happen as part of the Moodle upgrade process.

If an out-of-date plugin causes your upgrade to fail, you can usually delete the plugin code rather than uninstalling it from within Moodle so that the data associated with it is not deleted.

==Put your site into maintenance mode==
Before you begin upgrading your site, you should put it into [[Maintenance_mode | maintenance mode]] to stop any non-admin users from logging in. Then you should wait for any currently running cron processes to complete before proceeding.

== Install the new Moodle software ==
You can fetch the current version of the software at

wget https://download.moodle.org/download.php/stable38/moodle-3.8.2.zip

=== Standard install package ===

# Move your old Moodle software program files to another location. ''Do NOT copy new files over the old files.''
# Unzip or unpack the upgrade file so that all the new Moodle software program files are in the location the old files used to be in on the server. Moodle will adjust SQL and moodledata if it needs to in the upgrade.
# Copy your old [[Configuration file|config.php file]] back to the new Moodle directory.
# As mentioned above, if you had installed any plugins on your site you should add them to the new code tree (Moodle directory structure) now. It is important to check that you get the correct version for your new version of Moodle. Be particularly careful that you do not overwrite any code in the new version of Moodle and that you place the plugin folders in the correct directory (the same directory that they are in in the current installation.)
# Your moodledata folder should be located separately to your Moodle code folder and, as such, should not need anything done to it. Moodle 3.0 will throw a warning if it is located in a web accessible folder and the moodledata should never be located in the Moodle code folder. If you are moving your installation to a new server or new location on your server, then you will need to follow the [[Migration]] documents.

====Linux====
mv moodle moodle.backup
tar xvzf moodle-latest-{{Version}}.tgz

Next, copy across your config.php, any custom plugins, and your .htaccess file if you created one ('''check that custom plugins are the correct version for your new Moodle first'''):

cp moodle.backup/config.php moodle
cp -pr moodle.backup/theme/mytheme moodle/theme/mytheme
cp -pr moodle.backup/mod/mymod moodle/mod/mymod

Don't forget to make moodle/config.php (and the rest of the source code) readable by your www server. For maximum security the files should not be writeable by your server. This is especially important on a 'production' server open to the public internet.

chown -R root:root moodle (Linux debian - or even create a user especially for moodle. '''Don't''' use the web server user, e.g. www-data)
chmod -R 755 moodle

If you use cron, take care that cron.php is executeable and uses the correct php command:
chmod 740 admin/cli/cron.php (some configurations need chmod 750 or chmod 755)
copy the first line from cron.php (if it looks like '#!/usr/local/bin/php' or '#!/usr/local/bin/php5.3', no need to copy '<?php')
if necessary. However, for a simple upgrade, there should be no need to change anything with cron.

=== Using Git ===

You can use Git for updating or upgrading your Moodle. See [[Git for Administrators]] for details.

===Command line upgrade===

On Linux servers, Moodle {{Version}} supports running the [[CLI|upgrade from the command line]], rather than through a web browser. This is likely to be more reliable, particularly for large sites.

== Finishing the upgrade ==

The last step is to trigger the upgrade processes within Moodle.

If you put your site into Maintenance mode earlier; take it out now!

To do this just go to ''Site administration > Notifications''.

Moodle will automatically detect the new version and perform all the SQL database or file system upgrades that are necessary. If there is anything it can't do itself (very rare) then you will see messages telling you what you need to do.

Assuming all goes well (no error messages) then you can start using your new version of Moodle and enjoy the new features!

Note: If you are running multiple servers then you should purge all caches manually (via ''Site administration > Development > Purge all caches'') after completing the upgrade on all servers.

===Fatal error: Maximum execution time of 30 seconds exceeded...===

If your server uses a main language other than English, you may encounter a 'Fatal error: Maximum execution time of 30 seconds exceeded' when you try to upgrade it. You can increase max_execution_time = 160 on php.ini to allow the scripts enough time to process the language update. Otherwise, you can switch to English as the default language before doing the upgrade and back to your original language after a successful upgrade. See the forum discussion at https://moodle.org/mod/forum/discuss.php?d=119598.

==After upgrading==

==Possible issues that may affect you in Moodle {{Version}}==

===Course overview improvements===

New course overview settings enable an admin to

* reduce the currently available layouts (Card, List and Summary)
* specify which filter options are available, including providing a custom filter which uses course custom field values

===Course request changes===

The capabilities moodle/course:request and moodle/site:approvecourse may now be applied in the category context.

===Removed functionality===

* The Community finder block and course-sharing functionality have been removed as part of the preparations for the new MoodleNet open social media platform.
* The People block has been removed because there is a Participants link in the navigation drawer (Boost theme) and in the navigation block (Classic theme).

''Please add more items here...''

See also the list of [https://tracker.moodle.org/issues/?jql=project%20%3D%20mdl%20AND%20resolution%20%3D%20fixed%20AND%20fixVersion%20in%20(%223.8%22)%20AND%20labels%20%3D%20upgrade_notes upgrade_notes-labelled issues] and [https://tracker.moodle.org/issues/?jql=project%20%3D%20mdl%20AND%20resolution%20%3D%20fixed%20AND%20fixVersion%20in%20(%223.8%22)%20AND%20labels%20%3D%20ui_change%20 ui_change-labelled issues].

===New capabilities in Moodle {{Version}}===

'''Forum'''

* forumreport/summary:view
* forumreport/summary:viewall
* mod/forum:exportforum
* mod/forum:grade

'''H5P'''

* atto/h5p:addembed
* moodle/h5p:deploy
* moodle/h5p:setdisplayoptions
* moodle/h5p:updatelibraries

=== Moodle 3.2, 3.3, 3.4, 3.5, 3.6 and 3.7 improvements ===

Depending on which version you are upgrading from, please see the section 'Possible issues that may affect you' in the documentation

* [https://docs.moodle.org/32/en/Upgrading Upgrading to Moodle 3.2]
* [https://docs.moodle.org/33/en/Upgrading Upgrading to Moodle 3.3]
* [https://docs.moodle.org/34/en/Upgrading Upgrading to Moodle 3.4]
* [https://docs.moodle.org/35/en/Upgrading Upgrading to Moodle 3.5]
* [https://docs.moodle.org/36/en/Upgrading Upgrading to Moodle 3.6]
* [https://docs.moodle.org/37/en/Upgrading Upgrading to Moodle 3.7]

==Any questions about the process?==

Please post in the [https://moodle.org/mod/forum/view.php?id=28 Installing and upgrading help forum] on moodle.org.

==See also==

* [[dev:Moodle {{Version}} release notes|Moodle {{Version}} release notes]]
* [https://moodle.org/mod/forum/discuss.php?d=393570 Problem accessing dropdown such as personal profile since 3.8 (20191118) update] forum discussion

[[es:Actualización de moodle]]
[[fr:Mise à jour]]
[[ja:Moodleをアップグレードする]]
[[de:Aktualisierung von Moodle]]

Upgrading

2020-03-10T12:15:47Z

Howardsmiller: /* Install the new Moodle software */

{{Installing Moodle}}
''This page explains in detail how to upgrade Moodle. For a summary of the process, see [[Upgrade overview]].''

==Check the requirements==

Before upgrading, check that your server meets all requirements for {{Version}} in ''Site administration > Server > [[Environment]]''.

See the [{{Release notes}} release notes] in the dev docs for both [{{Release notes}}#Server_requirements server] and [{{Release notes}}#Client_requirements client] software requirements.

Notes:

* You can only upgrade to Moodle {{Version}} from Moodle 3.2 or later. If upgrading from earlier versions, you must [https://docs.moodle.org/32/en/Upgrading_to_Moodle_3.2 upgrade to 3.2] as a first step.

==Before upgrading==

'''We advise that you test the upgrade first on a COPY of your production site, to make sure it works as you expect.'''

Consider setting the [[Upgrade key|upgrade key]] for your site.

== Backup important data ==

There are three areas that should be backed up before any upgrade:
#Moodle software (For example, everything in server/htdocs/moodle)
#Moodle uploaded files (For example, server/moodledata)
#Moodle database (For example, your Postgres or MySQL database dump)

See [[Site backup]] for more specific information.

== Check for plugin updates ==

If you have [[Automatic updates deployment]] enabled, you will be able to update installed plugins automatically during the upgrade. Just make sure you check for available updates (via the button for it) at the Plugins check screen.

If you are updating plugins manually, it is a good moment now to check in the [http://moodle.org/plugins Moodle Plugins directory] whether there is a {{Version}} version available for any plugins (including themes) that you have previously installed on your site. If so, download the plugin package. In the next step, you will copy it to the appropriate location in your Moodle code (see [[Installing plugins]]).

The upgrade of the plugin will then happen as part of the Moodle upgrade process.

If an out-of-date plugin causes your upgrade to fail, you can usually delete the plugin code rather than uninstalling it from within Moodle so that the data associated with it is not deleted.

==Put your site into maintenance mode==
Before you begin upgrading your site, you should put it into [[Maintenance_mode | maintenance mode]] to stop any non-admin users from logging in. Then you should wait for any currently running cron processes to complete before proceeding.

== Install the new Moodle software ==
You can fetch the current version of the software at

https://download.moodle.org/releases/latest/

=== Standard install package ===

# Move your old Moodle software program files to another location. ''Do NOT copy new files over the old files.''
# Unzip or unpack the upgrade file so that all the new Moodle software program files are in the location the old files used to be in on the server. Moodle will adjust SQL and moodledata if it needs to in the upgrade.
# Copy your old [[Configuration file|config.php file]] back to the new Moodle directory.
# As mentioned above, if you had installed any plugins on your site you should add them to the new code tree (Moodle directory structure) now. It is important to check that you get the correct version for your new version of Moodle. Be particularly careful that you do not overwrite any code in the new version of Moodle and that you place the plugin folders in the correct directory (the same directory that they are in in the current installation.)
# Your moodledata folder should be located separately to your Moodle code folder and, as such, should not need anything done to it. Moodle 3.0 will throw a warning if it is located in a web accessible folder and the moodledata should never be located in the Moodle code folder. If you are moving your installation to a new server or new location on your server, then you will need to follow the [[Migration]] documents.

====Linux====
mv moodle moodle.backup
tar xvzf moodle-latest-{{Version}}.tgz

Next, copy across your config.php, any custom plugins, and your .htaccess file if you created one ('''check that custom plugins are the correct version for your new Moodle first'''):

cp moodle.backup/config.php moodle
cp -pr moodle.backup/theme/mytheme moodle/theme/mytheme
cp -pr moodle.backup/mod/mymod moodle/mod/mymod

Don't forget to make moodle/config.php (and the rest of the source code) readable by your www server. For maximum security the files should not be writeable by your server. This is especially important on a 'production' server open to the public internet.

chown -R root:root moodle (Linux debian - or even create a user especially for moodle. '''Don't''' use the web server user, e.g. www-data)
chmod -R 755 moodle

If you use cron, take care that cron.php is executeable and uses the correct php command:
chmod 740 admin/cli/cron.php (some configurations need chmod 750 or chmod 755)
copy the first line from cron.php (if it looks like '#!/usr/local/bin/php' or '#!/usr/local/bin/php5.3', no need to copy '<?php')
if necessary. However, for a simple upgrade, there should be no need to change anything with cron.

=== Using Git ===

You can use Git for updating or upgrading your Moodle. See [[Git for Administrators]] for details.

===Command line upgrade===

On Linux servers, Moodle {{Version}} supports running the [[CLI|upgrade from the command line]], rather than through a web browser. This is likely to be more reliable, particularly for large sites.

== Finishing the upgrade ==

The last step is to trigger the upgrade processes within Moodle.

If you put your site into Maintenance mode earlier; take it out now!

To do this just go to ''Site administration > Notifications''.

Moodle will automatically detect the new version and perform all the SQL database or file system upgrades that are necessary. If there is anything it can't do itself (very rare) then you will see messages telling you what you need to do.

Assuming all goes well (no error messages) then you can start using your new version of Moodle and enjoy the new features!

Note: If you are running multiple servers then you should purge all caches manually (via ''Site administration > Development > Purge all caches'') after completing the upgrade on all servers.

===Fatal error: Maximum execution time of 30 seconds exceeded...===

If your server uses a main language other than English, you may encounter a 'Fatal error: Maximum execution time of 30 seconds exceeded' when you try to upgrade it. You can increase max_execution_time = 160 on php.ini to allow the scripts enough time to process the language update. Otherwise, you can switch to English as the default language before doing the upgrade and back to your original language after a successful upgrade. See the forum discussion at https://moodle.org/mod/forum/discuss.php?d=119598.

==After upgrading==

==Possible issues that may affect you in Moodle {{Version}}==

===Course overview improvements===

New course overview settings enable an admin to

* reduce the currently available layouts (Card, List and Summary)
* specify which filter options are available, including providing a custom filter which uses course custom field values

===Course request changes===

The capabilities moodle/course:request and moodle/site:approvecourse may now be applied in the category context.

===Removed functionality===

* The Community finder block and course-sharing functionality have been removed as part of the preparations for the new MoodleNet open social media platform.
* The People block has been removed because there is a Participants link in the navigation drawer (Boost theme) and in the navigation block (Classic theme).

''Please add more items here...''

See also the list of [https://tracker.moodle.org/issues/?jql=project%20%3D%20mdl%20AND%20resolution%20%3D%20fixed%20AND%20fixVersion%20in%20(%223.8%22)%20AND%20labels%20%3D%20upgrade_notes upgrade_notes-labelled issues] and [https://tracker.moodle.org/issues/?jql=project%20%3D%20mdl%20AND%20resolution%20%3D%20fixed%20AND%20fixVersion%20in%20(%223.8%22)%20AND%20labels%20%3D%20ui_change%20 ui_change-labelled issues].

===New capabilities in Moodle {{Version}}===

'''Forum'''

* forumreport/summary:view
* forumreport/summary:viewall
* mod/forum:exportforum
* mod/forum:grade

'''H5P'''

* atto/h5p:addembed
* moodle/h5p:deploy
* moodle/h5p:setdisplayoptions
* moodle/h5p:updatelibraries

=== Moodle 3.2, 3.3, 3.4, 3.5, 3.6 and 3.7 improvements ===

Depending on which version you are upgrading from, please see the section 'Possible issues that may affect you' in the documentation

* [https://docs.moodle.org/32/en/Upgrading Upgrading to Moodle 3.2]
* [https://docs.moodle.org/33/en/Upgrading Upgrading to Moodle 3.3]
* [https://docs.moodle.org/34/en/Upgrading Upgrading to Moodle 3.4]
* [https://docs.moodle.org/35/en/Upgrading Upgrading to Moodle 3.5]
* [https://docs.moodle.org/36/en/Upgrading Upgrading to Moodle 3.6]
* [https://docs.moodle.org/37/en/Upgrading Upgrading to Moodle 3.7]

==Any questions about the process?==

Please post in the [https://moodle.org/mod/forum/view.php?id=28 Installing and upgrading help forum] on moodle.org.

==See also==

* [[dev:Moodle {{Version}} release notes|Moodle {{Version}} release notes]]
* [https://moodle.org/mod/forum/discuss.php?d=393570 Problem accessing dropdown such as personal profile since 3.8 (20191118) update] forum discussion

[[es:Actualización de moodle]]
[[fr:Mise à jour]]
[[ja:Moodleをアップグレードする]]
[[de:Aktualisierung von Moodle]]

Guest access

2020-02-06T09:35:59Z

Howardsmiller: It's not a plugin. It's core functionality

{{Enrolment}}
The Guest access facility allows users with the [[Guest_role |Guest role]] to view the contents of a course. This might be used, for example, if a Moodle site serves as a website where certain courses contain publicly available information, or else with a commercial Moodle site where courses with guest access can offers a "taster" of the kind of courses which may be purchased. (Note that the guest cannot participate in any activities; they can only view content.)

==Course settings for guest access==

{{MediaPlayer | url = https://youtu.be/9X8dVVRw52w | desc = How to allow guests into courses}}
# With the [[Boost theme]], from the navigation drawer on the left, click 'Participants', and then from the gear menu on the right, click 'Enrolment method> Guest access'. With other themes, click ''Administration > Course administration > Users > Enrolment methods'' and then Guest access.
#Enable guest access by clicking on the "eye" icon or by choosing it in the 'Add method' dropdown menu.
# If you wish to set a password, then click the configure icon and type in your password here.

==Admin settings for guest access==

{{MediaPlayer | url = https://youtu.be/KA9VdsqPhoM | desc = How to allow guests onto your Moodle site}}

*In ''Administration > Site administration > Plugins > Enrolments > Manage enrol plugins'',ensure Guest access is enabled (has its eye open.) This enables Guest access.
* In ''Administration > Site administration > Plugins > Authentication > Manage authentication'' set the Guest login button to Show if you want the button on the Front page.
* Also Guest accounts can be logged - check the ''Administration> Site administration > Plugins > Logging > Log guest access'' setting
* A site policy for guests may be set in ''Site administration > Security > Site policies''. Guests then have to agree to the site policy before accessing a course with guest access.

===Default settings for guest access===
*Clicking on ''Administration > Site administration > Plugins > Enrolments > Guest access'' brings up the screen where admin can set defaults for guest access in courses.
**Clicking the 'Advanced' button next to 'Allow guest access' will hide this setting in a course and will instead display a 'Show more' link to click on to access the setting.
** Guest access can be turned on by default in all new courses and you can also:
**require each course with guest access to have a password for guests. (Note: this can confuse teachers who are not aware of the requirement.)
**use or ignore your Moodle's standard password policy for guest access passwords
**offer if needed the first letter of the password as a hint.

===Auto-login guests===
*In ''Administration > Site administration > Users > Permissions > User policies'', you can tick the box so that visitors are automatically logged in as guests when accessing a course with guest access (i.e. they don't have to click the "login as guest button".
*In ''Administration > Site administration > Plugins > Authentication > Manage Authentication'', you must have "Guest login button" set to "Show".
*In ''Administration > Site administration > Security > Site policies'' you can check "Open to Google" setting so that the Google search robot will be allowed to enter your site as a Guest. In addition, people coming in to your site via a Google search will automatically be logged in as a Guest.

==See also==

* [[Guest role]]
* [https://moodle.org/mod/forum/discuss.php?d=347107#p1400235 Re: Guest access to course sections!] forum post
*Tracker discussion 'Auto-login guests not working' MDLSITE-4903
[[de:Gastzugang zum Kurs]]

[[es:Acceso de invitados]]

Performance recommendations

2019-09-30T08:10:31Z

Howardsmiller: /* PHP performance */

{{Performance}}
Moodle can be made to perform very well, at small usage levels or scaling up to many thousands of users. The factors involved in performance are basically the same as for any PHP-based database-driven system. When trying to optimize your server, try to focus on the factor which will make the most difference to the user. For example, if you have relatively more users browsing than accessing the database, look to improve the webserver performance.

==Obtain a baseline benchmark==

Before attempting any optimization, you should obtain a baseline benchmark of the component of the system you are trying to improve. For Linux try [http://lbs.sourceforge.net/ LBS] and for Windows use the Performance Monitor. Once you have quantitative data about how your system is performing currently, you'll be able to determine if the change you have made has had any real impact.

The overall aim of adjustments to improve performance is to use RAM (cacheing) and to reduce disk-based activity. It is especially important to try to eliminate swap file usage as much as you can. If your system starts swapping, this is a sign that you need more RAM.

The '''optimization order preference''' is usually: primary storage (more RAM), secondary storage (faster hard disks/improved hard disk configuration), processor (more and faster).

It can be interesting to install and use the [https://moodle.org/plugins/report_benchmark Benchmark plugin] in order to find the bottlenecks of your system that specifically affect Moodle.

==Scalability==

Moodle's design (with clear separation of application layers) allows for strongly scalable setups. (Please check the list of [[Large installations|large Moodle installations]].)

Large sites usually separate the web server and database onto separate servers, although for smaller installations this is typically not necessary.

It is possible to load-balance a Moodle installation, for example by using more than one webserver. The separate webservers should query the same database and refer to the same filestore and cache areas (see [[Caching]]), but otherwise the separation of the application layers is complete enough to make this kind of clustering feasible. Similarly, the database could be a cluster of servers (e.g. a MySQL cluster), but this is not an easy task and you should seek expert support, e.g. from a Moodle Partner.

On very large, load-balanced, systems the performance of the shared components become critical. It's important that your shared file areas are properly tuned and that you use an effective cache (Redis is highly recommended). A good understanding of these areas of system administration should be considered a minimum requirement.

===Server cluster===

Using Moodle forum discussions:

*[http://moodle.org/mod/forum/discuss.php?d=57202 Moodle clustering]
*[http://moodle.org/mod/forum/discuss.php?d=44470 Software load balancing]
*[http://moodle.org/mod/forum/discuss.php?d=49986 TCP load balancing]
*[http://moodle.org/mod/forum/discuss.php?d=88214 Installation for 3000 simultaneous users]

==Hardware configuration==
'''Note''': The fastest and most effective change that you can make to improve performance is to '''increase the amount of RAM on your web server''' - get as much as possible (e.g. 4GB or more). Increasing primary memory will reduce the need for processes to swap to disk and will enable your server to handle more users.
* Better performance is gained by obtaining the best '''processor capability''' you can, i.e. dual or dual core processors. A modern BIOS should allow you to enable hyperthreading, but check if this makes a difference to the overall performance of the processors by using a [http://en.wikipedia.org/wiki/Super_PI CPU benchmarking tool].
* If you can afford them, use '''SCSI hard disks''' instead of SATA drives. SATA drives will increase your system's CPU utilization, whereas SCSI drives have their own integrated processors and come into their own when you have multiple drives. If you must have SATA drives, check that your motherboard and the drives themselves support NCQ (Native Command Queuing).
* Purchase hard disks with a '''low seek time'''. This will improve the overall speed of your system, especially when accessing Moodle's reports.
* Size your '''swap file''' correctly. The general advice is to set it to 4 x physical RAM.
* Use a '''RAID disk system'''. Although there are many different RAID configurations you can create, the following generally works best:
** install a hardware RAID controller (if you can)
** the operating system and swap drive on one set of disks configured as RAID-1.
** Moodle, Web server and Database server on another set of disks configured as RAID-5.
* If your 'moodledata' area is going to be on relatively slow storage (e.g. NFS mount on to a NAS device) you will have performance issues with the default cache configuration (which writes to this storage). See the page on [[Caching]] and choose an alternative. Redis is recommended. Using [https://en.wikipedia.org/wiki/GlusterFS GlusterFS] / [https://en.wikipedia.org/wiki/OCFS2 OCFS2] / [https://en.wikipedia.org/wiki/GFS2 GFS2] on a [https://en.wikipedia.org/wiki/Storage_Area_Network SAN] device and [https://en.wikipedia.org/wiki/Fibre_Channel Fiber Channel] could improve performance (See more info on the Moodle [https://moodle.org/mod/forum/discuss.php?d=214680#p1123124 forum thread], [https://moodle.org/mod/forum/discuss.php?d=310501#p1242382 NFS performance tuing] )
* Use '''gigabit ethernet''' for improved latency and throughput. This is especially important when you have your webserver and database server separated out on different hosts.
* Check the settings on your '''network card'''. You may get an improvement in performance by increasing the use of buffers and transmit/receive descriptors (balance this with processor and memory overheads) and off-loading TCP checksum calculation onto the card instead of the OS.
* Read this [http://moodle.org/mod/forum/discuss.php?d=68579 Case Study] on a server stress test with 300 users.
* See this [http://elearning.sgu.ac.jp/doc/PT/ accompanying report] on network traffic and server loads.
* Also see this SFSU presentation at Educause (using VMWare): [http://www.educause.edu/Resources/AnOpenSourceLMSforaMissionCrit/162843]

==Operating System==
* You can use [http://en.wikipedia.org/wiki/Linux Linux](recommended), Unix-based, Windows or Mac OS X for the server '''operating system'''. *nix operating systems generally require less memory than Mac OS X or Windows servers for doing the same task as the server is configured with just a shell interface. Additionally Linux does not have licensing fees attached, but can have a big learning curve if you're used to another operating system. If you have a large number of processors running SMP, you may also want to consider using a highly tuned OS such as [http://en.wikipedia.org/wiki/Solaris_Operating_Environment Solaris].
* Check your own OS and '''vendor specific instructions''' for optimization steps.
** For Linux look at the [http://linuxperf.sourceforge.net/ Linux Performance Team] site.
** For Linux investigate the hdparm command, e.g. hdparm -m16 -d1 can be used to enable read/write on multiple sectors and DMA. Mount disks with the [https://moodle.org/mod/forum/discuss.php?d=310501#p1242382 "async" and "noatime"] options.
** For Windows set the sever to be optimized for network applications (Control Panel, Network Connections, LAN connection, Properties, File & Printer Sharing for Microsoft Networks, Properties, Optimization). You can also search the [http://technet.microsoft.com/ Microsoft TechNet site] for optimization documents.

==Web server performance==

Installing [http://www.mozilla.com/en-US/ Firefox] and the [https://addons.mozilla.org/en-US/firefox/addon/1843 firebug] extension will allow you to watch the time it takes for each page component to load. Also, the [https://addons.mozilla.org/en-US/firefox/addon/5369 Yslow] extension will evaluate your page against Yahoo's [http://www.skrenta.com/2007/05/14_rules_for_fast_web_pages_by_1.html 14 rules], full text [http://developer.yahoo.com/performance/rules.html Best Practices for Speeding Up Your Web Site], <strike>([http://video.yahoo.com/video/play?vid=1040890 video])</strike> for fast loading websites.

===PHP performance===
* PHP contains a built-in accelerator. Make sure it is enabled.
* Improvements in read/write performance can be improved by putting the cached PHP pages on a [[TMPFS]] filesystem - but remember that you'll lose the cache contents when there is a power failure or the server is rebooted.
* Performance of PHP is better when installed as an '''Apache/IIS6 ISAPI module''' (rather than a CGI). IIS 7.0/7.5 (Windows Server 2008/R2) users should choose a FastCGI installation for best performance.
* Also check the '''memory_limit''' in php.ini. The default value for the memory_limit directive is 128M. On some sites, it may need to be larger - especially for some backup operations.
* Also see [[PHP_settings_by_Moodle_version]]
* Use [http://blog.bitnami.com/2014/06/performance-enhacements-for-apache-and.html PHP-FPM] (with apache).

===Install HowTo===
==== APC ====
* [http://2bits.com/articles/installing-php-apc-gnulinux-centos-5.html APC on CentOS 5.x (linux)]
* [http://fplanque.com/dev/linux/install-apc-php-cache-debian-lenny APC on Debian (linux)]
==== eAccelerator ====
* [http://noveckg.blogspot.com/2010/02/installing-eaccelerator-cache-for-php.html Installing eAccelerator on CentOS 5.x (linux)]
* [https://docs.moodle.org/en/Installing_eAccelerator_In_Ubuntu_Server/ Installing eAccelerator on Ubuntu Server (linux)]
==== MemCached ====
Memcached server (daemon)
* [https://www.tecmint.com/install-memcached-on-centos-7/ Installing Memcached on CentOS 7.x (linux)] (as of php 7.x, only memcached is available)
* [https://www.digitalocean.com/community/tutorials/how-to-install-and-secure-memcached-on-centos-7 How To Install and Secure Memcached on CentOS 7]
* [https://wiki.zimbra.com/wiki/Blocking_Memcached_Attack#Iptables_rules_for_Redhat_based_servers Iptables rules for Redhat based servers]
Memcached PHP 7.1 extension
* [https://dl.iuscommunity.org/pub/ius/stable/CentOS/7/x86_64/repoview/php71u-pecl-memcached.html php71u-pecl-memcached] from IUS CentOS 7.x repository.

===Apache performance===
* If you are using Apache on a Windows server, use the build from [http://www.apachelounge.com Apache Lounge] which is reported to have [http://moodle.org/mod/forum/discuss.php?d=93358 performance and stability improvements] compared to the official Apache download. Note that this is an unofficial build, so may not keep up with official releases.
* Set the '''MaxRequestWorkers''' directive correctly ('''MaxClients''' before Apache 2.4). Use this formula to help (which uses 80% of available memory to leave room for spare):
MaxRequestWorkers = Total available memory * 80% / Max memory usage of apache process
:Memory usage of apache process is usually 10MB but Moodle can easily use up to 100MB per process, so a general rule of thumb is to divide your available memory in megabytes by 100 to get a conservative setting for MaxClients. You are quite likely to find yourself lowering the MaxRequestWorkers from its default of 150 on a Moodle server. To get a more accurate estimate read the value from the shell command:
#ps -ylC httpd --sort:rss

:If you need to increase the value of '''MaxRequestWorkers''' beyond 256, you will also need to set the '''ServerLimit''' directive.

:'''Warning''': Do not be tempted to set the value of MaxRequestWorkers higher than your available memory as your server will consume more RAM than available and start to swap to disk.
* Consider reducing the '''number of modules''' that Apache loads in the httpd.conf file to the minumum necessary to reduce the memory needed.
* Use the '''latest version of Apache''' - Apache 2 has an improved memory model which reduces memory usage further.
* For Unix/Linux systems, consider lowering '''MaxConnectionsPerChild''' ('''MaxRequestsPerChild''' before Apache 2.4) in httpd.conf to as low as 20-30 (if you set it any lower the overhead of forking begins to outweigh the benefits).
* For a heavily loaded server, consider setting '''KeepAlive Off''' (do this only if your Moodle pages do not contain links to resources or uploaded images) or lowering the '''KeepAliveTimeout''' to between 2 and 5. The default is 15 (seconds) - the higher the value the more server processes will be kept waiting for possibly idle connections. A more accurate value for KeepAliveTimeout is obtained by observing how long it takes your users to download a page. After altering any of the KeepAlive variables, monitor your CPU utilization as there may be an additional overhead in initiating more worker processes/threads.
* As an alternative to using KeepAlive Off, consider setting-up a '''Reverse Proxy server''' infront of the Moodle server to cache HTML files with images. You can then return Apache to using keep-alives on the Moodle server.
* If you do not use a .htaccess file, set the '''AllowOverride''' variable to AllowOverride None to prevent .htaccess lookups.
* Set '''DirectoryIndex''' correctly so as to avoid content-negotiation. Here's an example from a production server:
DirectoryIndex index.php index.html index.htm
* Unless you are doing development work on the server, set '''ExtendedStatus Off''' and disable mod_info as well as mod_status.
* Leave '''HostnameLookups Off''' (as default) to reduce DNS latency.
* Consider reducing the value of '''TimeOut''' to between 30 to 60 (seconds).
* For the '''Options directive''', avoid Options Multiviews as this performs a directory scan. To reduce disk I/O further use
Options -Indexes FollowSymLinks

* Compression reduces response times by reducing the size of the HTTP response
# Install and enable mod_deflate - refer to documentation or man pages
# Add this code to the virtual server config file within the <directory> section for the root directory (or within the .htaccess file if AllowOverrides is On):
<ifModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/x-js text/javascript text/css application/javascript
</ifmodule>
* Use Apache [http://blog.bitnami.com/2014/06/performance-enhacements-for-apache-and.html event] [http://httpd.apache.org/docs/current/mpm.html MPM] (and not the default Prefork or Worker)

===IIS performance===
All alter this location in the registry:
HKLM\SYSTEM\CurrentControlSet\Services\Inetinfo\Parameters\
* The equivalent to KeepAliveTimeout is '''ListenBackLog''' (IIS - registry location is HKLM\ SYSTEM\ CurrentControlSet\ Services\ Inetinfo\ Parameters). Set this to between 2 to 5.
*Change the '''MemCacheSize''' value to adjust the amount of memory (Mb) that IIS will use for its file cache (50% of available memory by default).
*Change the '''MaxCachedFileSize''' to adjust the maximum size of a file cached in the file cache in bytes. Default is 262,144 (256K).
*Create a new DWORD called '''ObjectCacheTTL''' to change the length of time (in milliseconds) that objects in the cache are held in memory. Default is 30,000 milliseconds (30 seconds).

===Lighttpd, NginX and Cherokee performance===
You can increase server performance by using a '''light-weight''' webserver like [http://www.lighttpd.net/ lighttpd], [http://nginx.net/ nginx] or [http://www.cherokee-project.com/ cherokee] in combination with PHP in FastCGI-mode. Lighttpd was originally created as a proof-of-concept[http://www.lighttpd.net/story] to address the [http://www.kegel.com/c10k.html C10k problem] and while primarily recommended for memory-limited servers, its design origins and asynchronous-IO model make it a suitable and proven[http://blog.lighttpd.net/articles/2006/12/28/lighttpd-powers-5-alexa-top-250-sites] alternative HTTP server for high-load websites and web apps, including Moodle. See the [[lighttpd | MoodleDocs Lighttpd page]] for additional information, configuration example and links.

Alternatively, both [http://www.lighttpd.net/ lighttpd] and [http://nginx.net/ nginx] are capable of performing as a load-balancer and/or reverse-proxy to alleviate load on back-end servers[http://www.linuxjournal.com/article/10108], providing benefit without requiring an actual software change on existing servers.

Do note that these are likely to be the least tested server environments of all particularly if you are using advanced features such as web services and/or Moodle Networking. They are probably best considered for heavily used Moodle sites with relatively simple configurations.

===X-Sendfile===

X-Sendfile modules improve performance when sending large files from Moodle. It is recommended to configure your web server and Moodle to use this feature of available.

Configure web server:
* Apache - https://tn123.org/mod_xsendfile/
* Lighttpd - http://redmine.lighttpd.net/projects/lighttpd/wiki/X-LIGHTTPD-send-file
* Nginx - http://wiki.nginx.org/XSendfile

Enable support in config.php (see config-dist.php):
<code php>
// $CFG->xsendfile = 'X-Sendfile'; // Apache {@see https://tn123.org/mod_xsendfile/}
// $CFG->xsendfile = 'X-LIGHTTPD-send-file'; // Lighttpd {@see http://redmine.lighttpd.net/projects/lighttpd/wiki/X-LIGHTTPD-send-file}
// $CFG->xsendfile = 'X-Accel-Redirect'; // Nginx {@see http://wiki.nginx.org/XSendfile}
</code>

Configure file location prefixes if your server implementation requires it:
<code php>
// $CFG->xsendfilealiases = array(
// '/dataroot/' => $CFG->dataroot,
// '/cachedir/' => '/var/www/moodle/cache', // for custom $CFG->cachedir locations
// '/localcachedir/' => '/var/local/cache', // for custom $CFG->localcachedir locations
// '/tempdir/' => '/var/www/moodle/temp', // for custom $CFG->tempdir locations
// '/filedir' => '/var/www/moodle/filedir', // for custom $CFG->filedir locations
// );
</code>

==Database performance==

===MySQL performance===

The following are MySQL specific settings which can be adjusted for better performance in your my.cnf (my.ini in Windows). The file contains a list of settings and their values. To see the current values use these commands
SHOW STATUS;
SHOW VARIABLES;
'''Important''': You must make backups of your database before attempting to change any MySQL server configuration. After any change to the my.cnf, restart mysqld.

If you are able, the [http://mysqltuner.com/ MySQLTuner] tool can be run against your MySQL server and will calculate appropriate configuration values for most of the following settings based on your current load, status and variables automatically.

* Enable the '''query cache''' with
query_cache_type = 1.
For most Moodle installs, set the following:
query_cache_size = 36M
query_cache_min_res_unit = 2K.
The query cache will improve performance if you are doing few updates on the database.
* Set the '''table cache''' correctly. For Moodle 1.6 set
table_cache = 256 #(table_open_cache in MySQL > 5.1.2)
(min), and for Moodle 1.7 set
table_cache = 512 #(table_open_cache in MySQL > 5.1.2)
(min). The table cache is used by all threads (connections), so monitor the value of opened_tables to further adjust - if opened_tables > 3 * table_cache(table_open_cache in MySQL > 5.1.2) then increase table_cache upto your OS limit. Note also that the figure for table_cache will also change depending on the number of modules and plugins you have installed. Find the number for your server by executing the mysql statement below. Look at the number returned and set table_cache to this value.
mysql>SELECT COUNT(table_name) FROM information_schema.tables WHERE table_schema='yourmoodledbname';
* Set the '''thread cache''' correctly. Adjust the value so that your thread cache utilization is as close to 100% as possible by this formula:
thread cache utilization (%) = (threads_created / connections) * 100
* The '''key buffer''' can improve the access speed to Moodle's SELECT queries. The correct size depends on the size of the index files (.myi) and in Moodle 1.6 or later (without any additional modules and plugins), the recommendation for this value is key_buffer_size = 32M. Ideally you want the database to be reading once from the disk for every 100 requests so monitor that the value is suitable for your install by adjusting the value of key_buffer_size so that the following formulas are true:
key_read / key_read_requests < 0.01
key_write / key_write_requests <= 1.0
* Set the '''maximum number of connections''' so that your users will not see a "Too many connections" message. Be careful that this may have an impact on the total memory used. MySQL connections usually last for milliseconds, so it is unusual even for a heavily loaded server for this value to be over 200.
* Manage '''high burst activity'''. If your Moodle install uses a lot of quizzes and you are experiencing performance problems (check by monitoring the value of threads_connected - it should not be rising) consider increasing the value of back_log.
* '''Optimize your tables weekly and after upgrading Moodle'''. It is good practice to also optimize your tables after performing a large data deletion exercise, e.g. at the end of your semester or academic year. This will ensure that index files are up to date. Backup your database first and then use:
mysql>CHECK TABLE mdl_tablename;
mysql>OPTIMIZE TABLE mdl_tablename;
:The common tables in Moodle to check are mdl_course_sections, mdl_forum_posts, mdl_log and mdl_sessions (if using dbsessions). Any errors need to be corrected using REPAIR TABLE (see the [http://dev.mysql.com/doc/refman/5.0/en/repair-table.html MySQL manual] and this [http://moodle.org/mod/forum/discuss.php?d=58208#p279638 forum script]).
* '''Maintain the key distribution'''. Every month or so it is a good idea to stop the mysql server and run these myisamchk commands.
#myisamchk -a -S /pathtomysql/data/moodledir/*.MYI
:'''Warning''': You must stop the mysql database process (mysqld) before running any myisamchk command. If you do not, you risk data loss.
* Reduce the number of '''temporary tables saved to disk'''. Check this with the created_tmp_disk_tables value. If this is relatively large (>5%) increase tmp_table_size until you see a reduction. Note that this will have an impact on RAM usage.

===PostgreSQL performance===

There are some good papers around on tuning PostgreSQL (like [http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server this one]), and Moodle's case does not seem to be different to the general case.

The first thing to recognise is that if you really need to worry about tuning you should be using a separate machine for the database server. If you are not using a separate machine then the answers to many performance questions are substantially muddied by the memory requirements of the rest of the application.

You should probably '''enable autovacuum''', unless you know what you are doing. Many e-learning sites have predictable periods of low use, so disabling autovacuum and running a specific vacuum at those times can be a good option. Or perhaps leave autovacuum running but do a full vacuum weekly in a quiet period.

Set '''shared_buffers''' to something reasonable. For versions up to 8.1 my testing has shown that peak performance is almost always obtained with buffers < 10000, so if you are using such a version, and have more than 512M of RAM just set shared_buffers to 10,000 (8MB).

The buffer management had a big overhaul in 8.2 and "reasonable" is now a much larger number. I have not conducted performance tests with 8.2, but the recommendations from others are generally that you should now scale shared_buffers much more with memory and may continue to reap benefits even up to values like 100,000 (80MB). Consider using 1-2% of system RAM.

PostgreSQL will also assume that the operating system is caching its files, so setting '''effective_cache_size''' to a reasonable value is also a good idea. A reasonable value will usually be (total RAM - RAM in use by programs). If you are running Linux and leave the system running for a day or two you can look at 'free' and under the 'cached' column you will see what it currently is. Consider taking that number (which is kB) and dividing it by 10 (i.e. allow 20% for other programs cache needs and then divide by 8 to get pages). If you are not using a dedicated database server you will need to decrease that value to account for usage by other programs.

Some other useful parameters that can have positive effects, and the values I would typically set them to on a machine with 4G RAM, are:

work_mem = 10240

That's 10M of RAM to use instead of on-disk sorting and so forth. That can give a big speed increase, but it is per connection and 200 connections * 10M is 2G, so it can theoretically chew up a lot of RAM.

maintenance_work_mem = 163840

That's 160M of RAM which will be used by (e.g.) VACUUM, index rebuild, cluster and so forth. This should only be used periodically and should be freed when those processes exit, so I believe it is well worth while.

wal_buffers = 64

These buffers are used for the write-ahead log, and there have been a number of reports on the PostgreSQL mailing lists of improvement from this level of increase.

This is a little out of date now (version 8.0) but still worth a read: http://www.powerpostgresql.com/Docs

And there is lots of good stuff here as well: http://www.varlena.com/GeneralBits/Tidbits/index.php

''Based on Andrew McMillan's post at [http://moodle.org/mod/forum/discuss.php?d=68558 Tuning PostgreSQL] forum thread.''

* Splitting '''mdl_log''' to several tables and using a VIEW with UNION to read them as one. (See Tim Hunt [https://moodle.org/mod/forum/discuss.php?d=243531#p1104165 explanation] on the Moodle forums)

===Other database performance links===
* Consider using a '''distributed cacheing system''' like [http://en.wikipedia.org/wiki/Memcached memcached] but note that memcached does not have any security features so it should be used behind a firewall.
* Consider using PostgreSQL. See [[Arguments in favour of PostgreSQL]] and [http://moodle.org/mod/forum/discuss.php?d=49195 how to migrate from MySQL to PostgreSQL] (forum discussion).
* [http://dev.mysql.com/doc/refman/5.0/en/server-parameters.html General advice on tuning MySQL parameters] (advice from the MySQL manual)
* [http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/ InnoDB performance optimization] taken from the [http://www.mysqlperformanceblog.com/ MySQL performance blog] site.

==Performance of different Moodle modules==

Moodle's activity modules, filters, and other plugins can be activated/deactivated. If necessary, you may wish to deactivate some features (such as chat) if not required - but this isn't necessary. Some notes on the performance of certain modules:

* The '''Chat''' module is [http://moodle.org/mod/forum/discuss.php?d=37979&parent=175079 said] to be a hog in terms of frequent HTTP requests to the main server. This can be reduced by setting the module to use ''Streamed'' updates, or, if you're using a Unix-based webserver, by running the chat in daemon mode. When using the Chat module use the configuration settings to tune for your expected load. Pay particular attention to the ''chat_old_ping'' and ''chat_refresh'' parameters as these can have greatest impact on server load.
* The Moodle '''Cron''' task is triggered by calling the script ''cron.php''. If this is called over HTTP (e.g. using wget or curl) it can take a large amount of memory on large installations. If it is called by directly invoking the php command (e.g. ''php -f /path/to/moodle/directory/admin/cli/cron.php'') efficiency can be much improved.
* The '''Recent activities''' block is consuming too many resources if you have huge number of records <code>mdl_log</code>. This is being tested to optimize the SQL query.
* The '''Quiz''' module is known to stretch database performance. However, it has been getting better in recent versions, and we don't know of any good, up-to-date performance measurements. (Here is a [http://moodle.org/mod/forum/discuss.php?d=68579 case study from 2007 with 300 quiz users].). The following suggestions were described by [https://moodle.org/user/view.php?id=94615&course=5 Al Rachels] in [https://moodle.org/mod/forum/discuss.php?d=347126 this forum thread]:
** make sure both Moodle, and the operating system, are installed on a [https://en.wikipedia.org/wiki/Solid-state_drive solid state drive]
** upgrade to and use [https://docs.moodle.org/dev/Moodle_and_PHP7 PHP 7]
** run MySQLTuner and implement its recommendations

See [[Performance settings]] for more information on performance-related Moodle settings.

==See also==

*Using Moodle: [http://moodle.org/mod/forum/view.php?f=94 Hardware and Performance] forum
*[http://opensourceelearning.blogspot.be/2012/10/why-your-moodle-site-is-slow-five.html Why Your Moodle Site is Slow: Five Simple Settings] blog post from Jonathan Moore
*I teach with Moodle perfomance testing: http://www.iteachwithmoodle.com/2012/11/17/moodle-2-4-beta-performance-test-comparison-with-moodle-2-3/
*[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.2 performance and MUC APC cahe store]
*[http://jfilip.ca/2013/09/25/moodle-performance-testing-2-4-6-vs-2-5-2-vs-2-6dev/ Moodle performance testing 2.4.6 vs 2.5.2 vs 2.6dev]
*[http://jfilip.ca/2013/09/24/moodle-performance-analysis-revisted-now-with-mariadb/ Moodle performance analysis revisited (now with MariaDB)]
*[http://tjhunt.blogspot.ca/2013/05/performance-testing-moodle.html Tim Hunt's blog (May 2, 2013) on performance testing Moodle]
*[http://newrelic.com/ New Relic, Application Performance Monitoring]
*[http://blog.bitnami.com/2014/06/performance-enhacements-for-apache-and.html Performance enhacements for Apache and PHP (Apache Event MPM and PHP-FPM)]
*[https://scholarlms.net/performance-recommendations/ Performance recommendations]

There have been a lot of discussions on moodle.org about performance, here are some of the more interesting and (potentially) useful ones:

* [http://moodle.org/mod/forum/discuss.php?d=83057 Performance woes!]
* [http://moodle.org/mod/forum/discuss.php?d=57028 Performance perspectives - a little script]
* [http://moodle.org/mod/forum/discuss.php?d=88927 Comments on planned server hardware]
* [http://moodle.org/mod/forum/discuss.php?d=102978#p461624 Moodle performance in a pil by Martin Langhoff]
* [https://moodle.org/mod/forum/discuss.php?d=240391#unread Advice on optimising php/db code in moodle2+]
* [https://moodle.org/mod/forum/discuss.php?d=243531 Moodle 2.5 performance testing at the OU]
* [https://moodle.org/mod/forum/discuss.php?d=273602 100 active users limit with 4vCPU]
* [https://moodle.org/mod/forum/discuss.php?d=336603#p1356423 Performance Tip ... shared...]

[[es:Recomendaciones sobre desempeño]]
[[fr:Performance]]
[[ja:パフォーマンス]]
[[de:Geschwindigkeitsempfehlungen]]

Performance recommendations

2019-09-30T08:08:28Z

Howardsmiller: /* Hardware configuration */

{{Performance}}
Moodle can be made to perform very well, at small usage levels or scaling up to many thousands of users. The factors involved in performance are basically the same as for any PHP-based database-driven system. When trying to optimize your server, try to focus on the factor which will make the most difference to the user. For example, if you have relatively more users browsing than accessing the database, look to improve the webserver performance.

==Obtain a baseline benchmark==

Before attempting any optimization, you should obtain a baseline benchmark of the component of the system you are trying to improve. For Linux try [http://lbs.sourceforge.net/ LBS] and for Windows use the Performance Monitor. Once you have quantitative data about how your system is performing currently, you'll be able to determine if the change you have made has had any real impact.

The overall aim of adjustments to improve performance is to use RAM (cacheing) and to reduce disk-based activity. It is especially important to try to eliminate swap file usage as much as you can. If your system starts swapping, this is a sign that you need more RAM.

The '''optimization order preference''' is usually: primary storage (more RAM), secondary storage (faster hard disks/improved hard disk configuration), processor (more and faster).

It can be interesting to install and use the [https://moodle.org/plugins/report_benchmark Benchmark plugin] in order to find the bottlenecks of your system that specifically affect Moodle.

==Scalability==

Moodle's design (with clear separation of application layers) allows for strongly scalable setups. (Please check the list of [[Large installations|large Moodle installations]].)

Large sites usually separate the web server and database onto separate servers, although for smaller installations this is typically not necessary.

It is possible to load-balance a Moodle installation, for example by using more than one webserver. The separate webservers should query the same database and refer to the same filestore and cache areas (see [[Caching]]), but otherwise the separation of the application layers is complete enough to make this kind of clustering feasible. Similarly, the database could be a cluster of servers (e.g. a MySQL cluster), but this is not an easy task and you should seek expert support, e.g. from a Moodle Partner.

On very large, load-balanced, systems the performance of the shared components become critical. It's important that your shared file areas are properly tuned and that you use an effective cache (Redis is highly recommended). A good understanding of these areas of system administration should be considered a minimum requirement.

===Server cluster===

Using Moodle forum discussions:

*[http://moodle.org/mod/forum/discuss.php?d=57202 Moodle clustering]
*[http://moodle.org/mod/forum/discuss.php?d=44470 Software load balancing]
*[http://moodle.org/mod/forum/discuss.php?d=49986 TCP load balancing]
*[http://moodle.org/mod/forum/discuss.php?d=88214 Installation for 3000 simultaneous users]

==Hardware configuration==
'''Note''': The fastest and most effective change that you can make to improve performance is to '''increase the amount of RAM on your web server''' - get as much as possible (e.g. 4GB or more). Increasing primary memory will reduce the need for processes to swap to disk and will enable your server to handle more users.
* Better performance is gained by obtaining the best '''processor capability''' you can, i.e. dual or dual core processors. A modern BIOS should allow you to enable hyperthreading, but check if this makes a difference to the overall performance of the processors by using a [http://en.wikipedia.org/wiki/Super_PI CPU benchmarking tool].
* If you can afford them, use '''SCSI hard disks''' instead of SATA drives. SATA drives will increase your system's CPU utilization, whereas SCSI drives have their own integrated processors and come into their own when you have multiple drives. If you must have SATA drives, check that your motherboard and the drives themselves support NCQ (Native Command Queuing).
* Purchase hard disks with a '''low seek time'''. This will improve the overall speed of your system, especially when accessing Moodle's reports.
* Size your '''swap file''' correctly. The general advice is to set it to 4 x physical RAM.
* Use a '''RAID disk system'''. Although there are many different RAID configurations you can create, the following generally works best:
** install a hardware RAID controller (if you can)
** the operating system and swap drive on one set of disks configured as RAID-1.
** Moodle, Web server and Database server on another set of disks configured as RAID-5.
* If your 'moodledata' area is going to be on relatively slow storage (e.g. NFS mount on to a NAS device) you will have performance issues with the default cache configuration (which writes to this storage). See the page on [[Caching]] and choose an alternative. Redis is recommended. Using [https://en.wikipedia.org/wiki/GlusterFS GlusterFS] / [https://en.wikipedia.org/wiki/OCFS2 OCFS2] / [https://en.wikipedia.org/wiki/GFS2 GFS2] on a [https://en.wikipedia.org/wiki/Storage_Area_Network SAN] device and [https://en.wikipedia.org/wiki/Fibre_Channel Fiber Channel] could improve performance (See more info on the Moodle [https://moodle.org/mod/forum/discuss.php?d=214680#p1123124 forum thread], [https://moodle.org/mod/forum/discuss.php?d=310501#p1242382 NFS performance tuing] )
* Use '''gigabit ethernet''' for improved latency and throughput. This is especially important when you have your webserver and database server separated out on different hosts.
* Check the settings on your '''network card'''. You may get an improvement in performance by increasing the use of buffers and transmit/receive descriptors (balance this with processor and memory overheads) and off-loading TCP checksum calculation onto the card instead of the OS.
* Read this [http://moodle.org/mod/forum/discuss.php?d=68579 Case Study] on a server stress test with 300 users.
* See this [http://elearning.sgu.ac.jp/doc/PT/ accompanying report] on network traffic and server loads.
* Also see this SFSU presentation at Educause (using VMWare): [http://www.educause.edu/Resources/AnOpenSourceLMSforaMissionCrit/162843]

==Operating System==
* You can use [http://en.wikipedia.org/wiki/Linux Linux](recommended), Unix-based, Windows or Mac OS X for the server '''operating system'''. *nix operating systems generally require less memory than Mac OS X or Windows servers for doing the same task as the server is configured with just a shell interface. Additionally Linux does not have licensing fees attached, but can have a big learning curve if you're used to another operating system. If you have a large number of processors running SMP, you may also want to consider using a highly tuned OS such as [http://en.wikipedia.org/wiki/Solaris_Operating_Environment Solaris].
* Check your own OS and '''vendor specific instructions''' for optimization steps.
** For Linux look at the [http://linuxperf.sourceforge.net/ Linux Performance Team] site.
** For Linux investigate the hdparm command, e.g. hdparm -m16 -d1 can be used to enable read/write on multiple sectors and DMA. Mount disks with the [https://moodle.org/mod/forum/discuss.php?d=310501#p1242382 "async" and "noatime"] options.
** For Windows set the sever to be optimized for network applications (Control Panel, Network Connections, LAN connection, Properties, File & Printer Sharing for Microsoft Networks, Properties, Optimization). You can also search the [http://technet.microsoft.com/ Microsoft TechNet site] for optimization documents.

==Web server performance==

Installing [http://www.mozilla.com/en-US/ Firefox] and the [https://addons.mozilla.org/en-US/firefox/addon/1843 firebug] extension will allow you to watch the time it takes for each page component to load. Also, the [https://addons.mozilla.org/en-US/firefox/addon/5369 Yslow] extension will evaluate your page against Yahoo's [http://www.skrenta.com/2007/05/14_rules_for_fast_web_pages_by_1.html 14 rules], full text [http://developer.yahoo.com/performance/rules.html Best Practices for Speeding Up Your Web Site], <strike>([http://video.yahoo.com/video/play?vid=1040890 video])</strike> for fast loading websites.

===PHP performance===
* You are strongly recommended to use a '''PHP accelerator''' to ease CPU load, such as [http://pecl.php.net/apc APC], [http://www.php-accelerator.co.uk/ PHPA], [http://trac.lighttpd.net/xcache/ Xcache], [http://sourceforge.net/projects/wincache WinCache] or [http://eaccelerator.net/ eAccelerator]. (Take care to choose a PHP accelerator that is known to work well with your version of PHP and note that Turck MMCache is [http://turckmmcache.exeprod.com/TheManifestoEnglish no longer maintained] and can cause failures with PHP 5). PHP 5.5 (and newer) includes OpCache and is fully supported and recommended by Moodle
* Improvements in read/write performance can be improved by putting the cached PHP pages on a [[TMPFS]] filesystem - but remember that you'll lose the cache contents when there is a power failure or the server is rebooted.
* Performance of PHP is better when installed as an '''Apache/IIS6 ISAPI module''' (rather than a CGI). IIS 7.0/7.5 (Windows Server 2008/R2) users should choose a FastCGI installation for best performance.
* Also check the '''memory_limit''' in php.ini, reduce it to 16M for Moodle version earlier than 1.7 ([http://moodle.org/mod/forum/discuss.php?d=39656 See this forum discussion]). For Moodle 1.7 or later, it is recommended that the value of memory_limit should be 40M. As of [http://www.php.net/ChangeLog-5.php PHP 5.2.1] the default value for the memory_limit directive is 128M.
* Also see [[PHP_settings_by_Moodle_version]]
* Use [http://blog.bitnami.com/2014/06/performance-enhacements-for-apache-and.html PHP-FPM] (with apache).

===Install HowTo===
==== APC ====
* [http://2bits.com/articles/installing-php-apc-gnulinux-centos-5.html APC on CentOS 5.x (linux)]
* [http://fplanque.com/dev/linux/install-apc-php-cache-debian-lenny APC on Debian (linux)]
==== eAccelerator ====
* [http://noveckg.blogspot.com/2010/02/installing-eaccelerator-cache-for-php.html Installing eAccelerator on CentOS 5.x (linux)]
* [https://docs.moodle.org/en/Installing_eAccelerator_In_Ubuntu_Server/ Installing eAccelerator on Ubuntu Server (linux)]
==== MemCached ====
Memcached server (daemon)
* [https://www.tecmint.com/install-memcached-on-centos-7/ Installing Memcached on CentOS 7.x (linux)] (as of php 7.x, only memcached is available)
* [https://www.digitalocean.com/community/tutorials/how-to-install-and-secure-memcached-on-centos-7 How To Install and Secure Memcached on CentOS 7]
* [https://wiki.zimbra.com/wiki/Blocking_Memcached_Attack#Iptables_rules_for_Redhat_based_servers Iptables rules for Redhat based servers]
Memcached PHP 7.1 extension
* [https://dl.iuscommunity.org/pub/ius/stable/CentOS/7/x86_64/repoview/php71u-pecl-memcached.html php71u-pecl-memcached] from IUS CentOS 7.x repository.

===Apache performance===
* If you are using Apache on a Windows server, use the build from [http://www.apachelounge.com Apache Lounge] which is reported to have [http://moodle.org/mod/forum/discuss.php?d=93358 performance and stability improvements] compared to the official Apache download. Note that this is an unofficial build, so may not keep up with official releases.
* Set the '''MaxRequestWorkers''' directive correctly ('''MaxClients''' before Apache 2.4). Use this formula to help (which uses 80% of available memory to leave room for spare):
MaxRequestWorkers = Total available memory * 80% / Max memory usage of apache process
:Memory usage of apache process is usually 10MB but Moodle can easily use up to 100MB per process, so a general rule of thumb is to divide your available memory in megabytes by 100 to get a conservative setting for MaxClients. You are quite likely to find yourself lowering the MaxRequestWorkers from its default of 150 on a Moodle server. To get a more accurate estimate read the value from the shell command:
#ps -ylC httpd --sort:rss

:If you need to increase the value of '''MaxRequestWorkers''' beyond 256, you will also need to set the '''ServerLimit''' directive.

:'''Warning''': Do not be tempted to set the value of MaxRequestWorkers higher than your available memory as your server will consume more RAM than available and start to swap to disk.
* Consider reducing the '''number of modules''' that Apache loads in the httpd.conf file to the minumum necessary to reduce the memory needed.
* Use the '''latest version of Apache''' - Apache 2 has an improved memory model which reduces memory usage further.
* For Unix/Linux systems, consider lowering '''MaxConnectionsPerChild''' ('''MaxRequestsPerChild''' before Apache 2.4) in httpd.conf to as low as 20-30 (if you set it any lower the overhead of forking begins to outweigh the benefits).
* For a heavily loaded server, consider setting '''KeepAlive Off''' (do this only if your Moodle pages do not contain links to resources or uploaded images) or lowering the '''KeepAliveTimeout''' to between 2 and 5. The default is 15 (seconds) - the higher the value the more server processes will be kept waiting for possibly idle connections. A more accurate value for KeepAliveTimeout is obtained by observing how long it takes your users to download a page. After altering any of the KeepAlive variables, monitor your CPU utilization as there may be an additional overhead in initiating more worker processes/threads.
* As an alternative to using KeepAlive Off, consider setting-up a '''Reverse Proxy server''' infront of the Moodle server to cache HTML files with images. You can then return Apache to using keep-alives on the Moodle server.
* If you do not use a .htaccess file, set the '''AllowOverride''' variable to AllowOverride None to prevent .htaccess lookups.
* Set '''DirectoryIndex''' correctly so as to avoid content-negotiation. Here's an example from a production server:
DirectoryIndex index.php index.html index.htm
* Unless you are doing development work on the server, set '''ExtendedStatus Off''' and disable mod_info as well as mod_status.
* Leave '''HostnameLookups Off''' (as default) to reduce DNS latency.
* Consider reducing the value of '''TimeOut''' to between 30 to 60 (seconds).
* For the '''Options directive''', avoid Options Multiviews as this performs a directory scan. To reduce disk I/O further use
Options -Indexes FollowSymLinks

* Compression reduces response times by reducing the size of the HTTP response
# Install and enable mod_deflate - refer to documentation or man pages
# Add this code to the virtual server config file within the <directory> section for the root directory (or within the .htaccess file if AllowOverrides is On):
<ifModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/x-js text/javascript text/css application/javascript
</ifmodule>
* Use Apache [http://blog.bitnami.com/2014/06/performance-enhacements-for-apache-and.html event] [http://httpd.apache.org/docs/current/mpm.html MPM] (and not the default Prefork or Worker)

===IIS performance===
All alter this location in the registry:
HKLM\SYSTEM\CurrentControlSet\Services\Inetinfo\Parameters\
* The equivalent to KeepAliveTimeout is '''ListenBackLog''' (IIS - registry location is HKLM\ SYSTEM\ CurrentControlSet\ Services\ Inetinfo\ Parameters). Set this to between 2 to 5.
*Change the '''MemCacheSize''' value to adjust the amount of memory (Mb) that IIS will use for its file cache (50% of available memory by default).
*Change the '''MaxCachedFileSize''' to adjust the maximum size of a file cached in the file cache in bytes. Default is 262,144 (256K).
*Create a new DWORD called '''ObjectCacheTTL''' to change the length of time (in milliseconds) that objects in the cache are held in memory. Default is 30,000 milliseconds (30 seconds).

===Lighttpd, NginX and Cherokee performance===
You can increase server performance by using a '''light-weight''' webserver like [http://www.lighttpd.net/ lighttpd], [http://nginx.net/ nginx] or [http://www.cherokee-project.com/ cherokee] in combination with PHP in FastCGI-mode. Lighttpd was originally created as a proof-of-concept[http://www.lighttpd.net/story] to address the [http://www.kegel.com/c10k.html C10k problem] and while primarily recommended for memory-limited servers, its design origins and asynchronous-IO model make it a suitable and proven[http://blog.lighttpd.net/articles/2006/12/28/lighttpd-powers-5-alexa-top-250-sites] alternative HTTP server for high-load websites and web apps, including Moodle. See the [[lighttpd | MoodleDocs Lighttpd page]] for additional information, configuration example and links.

Alternatively, both [http://www.lighttpd.net/ lighttpd] and [http://nginx.net/ nginx] are capable of performing as a load-balancer and/or reverse-proxy to alleviate load on back-end servers[http://www.linuxjournal.com/article/10108], providing benefit without requiring an actual software change on existing servers.

Do note that these are likely to be the least tested server environments of all particularly if you are using advanced features such as web services and/or Moodle Networking. They are probably best considered for heavily used Moodle sites with relatively simple configurations.

===X-Sendfile===

X-Sendfile modules improve performance when sending large files from Moodle. It is recommended to configure your web server and Moodle to use this feature of available.

Configure web server:
* Apache - https://tn123.org/mod_xsendfile/
* Lighttpd - http://redmine.lighttpd.net/projects/lighttpd/wiki/X-LIGHTTPD-send-file
* Nginx - http://wiki.nginx.org/XSendfile

Enable support in config.php (see config-dist.php):
<code php>
// $CFG->xsendfile = 'X-Sendfile'; // Apache {@see https://tn123.org/mod_xsendfile/}
// $CFG->xsendfile = 'X-LIGHTTPD-send-file'; // Lighttpd {@see http://redmine.lighttpd.net/projects/lighttpd/wiki/X-LIGHTTPD-send-file}
// $CFG->xsendfile = 'X-Accel-Redirect'; // Nginx {@see http://wiki.nginx.org/XSendfile}
</code>

Configure file location prefixes if your server implementation requires it:
<code php>
// $CFG->xsendfilealiases = array(
// '/dataroot/' => $CFG->dataroot,
// '/cachedir/' => '/var/www/moodle/cache', // for custom $CFG->cachedir locations
// '/localcachedir/' => '/var/local/cache', // for custom $CFG->localcachedir locations
// '/tempdir/' => '/var/www/moodle/temp', // for custom $CFG->tempdir locations
// '/filedir' => '/var/www/moodle/filedir', // for custom $CFG->filedir locations
// );
</code>

==Database performance==

===MySQL performance===

The following are MySQL specific settings which can be adjusted for better performance in your my.cnf (my.ini in Windows). The file contains a list of settings and their values. To see the current values use these commands
SHOW STATUS;
SHOW VARIABLES;
'''Important''': You must make backups of your database before attempting to change any MySQL server configuration. After any change to the my.cnf, restart mysqld.

If you are able, the [http://mysqltuner.com/ MySQLTuner] tool can be run against your MySQL server and will calculate appropriate configuration values for most of the following settings based on your current load, status and variables automatically.

* Enable the '''query cache''' with
query_cache_type = 1.
For most Moodle installs, set the following:
query_cache_size = 36M
query_cache_min_res_unit = 2K.
The query cache will improve performance if you are doing few updates on the database.
* Set the '''table cache''' correctly. For Moodle 1.6 set
table_cache = 256 #(table_open_cache in MySQL > 5.1.2)
(min), and for Moodle 1.7 set
table_cache = 512 #(table_open_cache in MySQL > 5.1.2)
(min). The table cache is used by all threads (connections), so monitor the value of opened_tables to further adjust - if opened_tables > 3 * table_cache(table_open_cache in MySQL > 5.1.2) then increase table_cache upto your OS limit. Note also that the figure for table_cache will also change depending on the number of modules and plugins you have installed. Find the number for your server by executing the mysql statement below. Look at the number returned and set table_cache to this value.
mysql>SELECT COUNT(table_name) FROM information_schema.tables WHERE table_schema='yourmoodledbname';
* Set the '''thread cache''' correctly. Adjust the value so that your thread cache utilization is as close to 100% as possible by this formula:
thread cache utilization (%) = (threads_created / connections) * 100
* The '''key buffer''' can improve the access speed to Moodle's SELECT queries. The correct size depends on the size of the index files (.myi) and in Moodle 1.6 or later (without any additional modules and plugins), the recommendation for this value is key_buffer_size = 32M. Ideally you want the database to be reading once from the disk for every 100 requests so monitor that the value is suitable for your install by adjusting the value of key_buffer_size so that the following formulas are true:
key_read / key_read_requests < 0.01
key_write / key_write_requests <= 1.0
* Set the '''maximum number of connections''' so that your users will not see a "Too many connections" message. Be careful that this may have an impact on the total memory used. MySQL connections usually last for milliseconds, so it is unusual even for a heavily loaded server for this value to be over 200.
* Manage '''high burst activity'''. If your Moodle install uses a lot of quizzes and you are experiencing performance problems (check by monitoring the value of threads_connected - it should not be rising) consider increasing the value of back_log.
* '''Optimize your tables weekly and after upgrading Moodle'''. It is good practice to also optimize your tables after performing a large data deletion exercise, e.g. at the end of your semester or academic year. This will ensure that index files are up to date. Backup your database first and then use:
mysql>CHECK TABLE mdl_tablename;
mysql>OPTIMIZE TABLE mdl_tablename;
:The common tables in Moodle to check are mdl_course_sections, mdl_forum_posts, mdl_log and mdl_sessions (if using dbsessions). Any errors need to be corrected using REPAIR TABLE (see the [http://dev.mysql.com/doc/refman/5.0/en/repair-table.html MySQL manual] and this [http://moodle.org/mod/forum/discuss.php?d=58208#p279638 forum script]).
* '''Maintain the key distribution'''. Every month or so it is a good idea to stop the mysql server and run these myisamchk commands.
#myisamchk -a -S /pathtomysql/data/moodledir/*.MYI
:'''Warning''': You must stop the mysql database process (mysqld) before running any myisamchk command. If you do not, you risk data loss.
* Reduce the number of '''temporary tables saved to disk'''. Check this with the created_tmp_disk_tables value. If this is relatively large (>5%) increase tmp_table_size until you see a reduction. Note that this will have an impact on RAM usage.

===PostgreSQL performance===

There are some good papers around on tuning PostgreSQL (like [http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server this one]), and Moodle's case does not seem to be different to the general case.

The first thing to recognise is that if you really need to worry about tuning you should be using a separate machine for the database server. If you are not using a separate machine then the answers to many performance questions are substantially muddied by the memory requirements of the rest of the application.

You should probably '''enable autovacuum''', unless you know what you are doing. Many e-learning sites have predictable periods of low use, so disabling autovacuum and running a specific vacuum at those times can be a good option. Or perhaps leave autovacuum running but do a full vacuum weekly in a quiet period.

Set '''shared_buffers''' to something reasonable. For versions up to 8.1 my testing has shown that peak performance is almost always obtained with buffers < 10000, so if you are using such a version, and have more than 512M of RAM just set shared_buffers to 10,000 (8MB).

The buffer management had a big overhaul in 8.2 and "reasonable" is now a much larger number. I have not conducted performance tests with 8.2, but the recommendations from others are generally that you should now scale shared_buffers much more with memory and may continue to reap benefits even up to values like 100,000 (80MB). Consider using 1-2% of system RAM.

PostgreSQL will also assume that the operating system is caching its files, so setting '''effective_cache_size''' to a reasonable value is also a good idea. A reasonable value will usually be (total RAM - RAM in use by programs). If you are running Linux and leave the system running for a day or two you can look at 'free' and under the 'cached' column you will see what it currently is. Consider taking that number (which is kB) and dividing it by 10 (i.e. allow 20% for other programs cache needs and then divide by 8 to get pages). If you are not using a dedicated database server you will need to decrease that value to account for usage by other programs.

Some other useful parameters that can have positive effects, and the values I would typically set them to on a machine with 4G RAM, are:

work_mem = 10240

That's 10M of RAM to use instead of on-disk sorting and so forth. That can give a big speed increase, but it is per connection and 200 connections * 10M is 2G, so it can theoretically chew up a lot of RAM.

maintenance_work_mem = 163840

That's 160M of RAM which will be used by (e.g.) VACUUM, index rebuild, cluster and so forth. This should only be used periodically and should be freed when those processes exit, so I believe it is well worth while.

wal_buffers = 64

These buffers are used for the write-ahead log, and there have been a number of reports on the PostgreSQL mailing lists of improvement from this level of increase.

This is a little out of date now (version 8.0) but still worth a read: http://www.powerpostgresql.com/Docs

And there is lots of good stuff here as well: http://www.varlena.com/GeneralBits/Tidbits/index.php

''Based on Andrew McMillan's post at [http://moodle.org/mod/forum/discuss.php?d=68558 Tuning PostgreSQL] forum thread.''

* Splitting '''mdl_log''' to several tables and using a VIEW with UNION to read them as one. (See Tim Hunt [https://moodle.org/mod/forum/discuss.php?d=243531#p1104165 explanation] on the Moodle forums)

===Other database performance links===
* Consider using a '''distributed cacheing system''' like [http://en.wikipedia.org/wiki/Memcached memcached] but note that memcached does not have any security features so it should be used behind a firewall.
* Consider using PostgreSQL. See [[Arguments in favour of PostgreSQL]] and [http://moodle.org/mod/forum/discuss.php?d=49195 how to migrate from MySQL to PostgreSQL] (forum discussion).
* [http://dev.mysql.com/doc/refman/5.0/en/server-parameters.html General advice on tuning MySQL parameters] (advice from the MySQL manual)
* [http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/ InnoDB performance optimization] taken from the [http://www.mysqlperformanceblog.com/ MySQL performance blog] site.

==Performance of different Moodle modules==

Moodle's activity modules, filters, and other plugins can be activated/deactivated. If necessary, you may wish to deactivate some features (such as chat) if not required - but this isn't necessary. Some notes on the performance of certain modules:

* The '''Chat''' module is [http://moodle.org/mod/forum/discuss.php?d=37979&parent=175079 said] to be a hog in terms of frequent HTTP requests to the main server. This can be reduced by setting the module to use ''Streamed'' updates, or, if you're using a Unix-based webserver, by running the chat in daemon mode. When using the Chat module use the configuration settings to tune for your expected load. Pay particular attention to the ''chat_old_ping'' and ''chat_refresh'' parameters as these can have greatest impact on server load.
* The Moodle '''Cron''' task is triggered by calling the script ''cron.php''. If this is called over HTTP (e.g. using wget or curl) it can take a large amount of memory on large installations. If it is called by directly invoking the php command (e.g. ''php -f /path/to/moodle/directory/admin/cli/cron.php'') efficiency can be much improved.
* The '''Recent activities''' block is consuming too many resources if you have huge number of records <code>mdl_log</code>. This is being tested to optimize the SQL query.
* The '''Quiz''' module is known to stretch database performance. However, it has been getting better in recent versions, and we don't know of any good, up-to-date performance measurements. (Here is a [http://moodle.org/mod/forum/discuss.php?d=68579 case study from 2007 with 300 quiz users].). The following suggestions were described by [https://moodle.org/user/view.php?id=94615&course=5 Al Rachels] in [https://moodle.org/mod/forum/discuss.php?d=347126 this forum thread]:
** make sure both Moodle, and the operating system, are installed on a [https://en.wikipedia.org/wiki/Solid-state_drive solid state drive]
** upgrade to and use [https://docs.moodle.org/dev/Moodle_and_PHP7 PHP 7]
** run MySQLTuner and implement its recommendations

See [[Performance settings]] for more information on performance-related Moodle settings.

==See also==

*Using Moodle: [http://moodle.org/mod/forum/view.php?f=94 Hardware and Performance] forum
*[http://opensourceelearning.blogspot.be/2012/10/why-your-moodle-site-is-slow-five.html Why Your Moodle Site is Slow: Five Simple Settings] blog post from Jonathan Moore
*I teach with Moodle perfomance testing: http://www.iteachwithmoodle.com/2012/11/17/moodle-2-4-beta-performance-test-comparison-with-moodle-2-3/
*[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.2 performance and MUC APC cahe store]
*[http://jfilip.ca/2013/09/25/moodle-performance-testing-2-4-6-vs-2-5-2-vs-2-6dev/ Moodle performance testing 2.4.6 vs 2.5.2 vs 2.6dev]
*[http://jfilip.ca/2013/09/24/moodle-performance-analysis-revisted-now-with-mariadb/ Moodle performance analysis revisited (now with MariaDB)]
*[http://tjhunt.blogspot.ca/2013/05/performance-testing-moodle.html Tim Hunt's blog (May 2, 2013) on performance testing Moodle]
*[http://newrelic.com/ New Relic, Application Performance Monitoring]
*[http://blog.bitnami.com/2014/06/performance-enhacements-for-apache-and.html Performance enhacements for Apache and PHP (Apache Event MPM and PHP-FPM)]
*[https://scholarlms.net/performance-recommendations/ Performance recommendations]

There have been a lot of discussions on moodle.org about performance, here are some of the more interesting and (potentially) useful ones:

* [http://moodle.org/mod/forum/discuss.php?d=83057 Performance woes!]
* [http://moodle.org/mod/forum/discuss.php?d=57028 Performance perspectives - a little script]
* [http://moodle.org/mod/forum/discuss.php?d=88927 Comments on planned server hardware]
* [http://moodle.org/mod/forum/discuss.php?d=102978#p461624 Moodle performance in a pil by Martin Langhoff]
* [https://moodle.org/mod/forum/discuss.php?d=240391#unread Advice on optimising php/db code in moodle2+]
* [https://moodle.org/mod/forum/discuss.php?d=243531 Moodle 2.5 performance testing at the OU]
* [https://moodle.org/mod/forum/discuss.php?d=273602 100 active users limit with 4vCPU]
* [https://moodle.org/mod/forum/discuss.php?d=336603#p1356423 Performance Tip ... shared...]

[[es:Recomendaciones sobre desempeño]]
[[fr:Performance]]
[[ja:パフォーマンス]]
[[de:Geschwindigkeitsempfehlungen]]

Performance recommendations

2019-09-30T08:07:09Z

Howardsmiller: /* Scalability */

{{Performance}}
Moodle can be made to perform very well, at small usage levels or scaling up to many thousands of users. The factors involved in performance are basically the same as for any PHP-based database-driven system. When trying to optimize your server, try to focus on the factor which will make the most difference to the user. For example, if you have relatively more users browsing than accessing the database, look to improve the webserver performance.

==Obtain a baseline benchmark==

Before attempting any optimization, you should obtain a baseline benchmark of the component of the system you are trying to improve. For Linux try [http://lbs.sourceforge.net/ LBS] and for Windows use the Performance Monitor. Once you have quantitative data about how your system is performing currently, you'll be able to determine if the change you have made has had any real impact.

The overall aim of adjustments to improve performance is to use RAM (cacheing) and to reduce disk-based activity. It is especially important to try to eliminate swap file usage as much as you can. If your system starts swapping, this is a sign that you need more RAM.

The '''optimization order preference''' is usually: primary storage (more RAM), secondary storage (faster hard disks/improved hard disk configuration), processor (more and faster).

It can be interesting to install and use the [https://moodle.org/plugins/report_benchmark Benchmark plugin] in order to find the bottlenecks of your system that specifically affect Moodle.

==Scalability==

Moodle's design (with clear separation of application layers) allows for strongly scalable setups. (Please check the list of [[Large installations|large Moodle installations]].)

Large sites usually separate the web server and database onto separate servers, although for smaller installations this is typically not necessary.

It is possible to load-balance a Moodle installation, for example by using more than one webserver. The separate webservers should query the same database and refer to the same filestore and cache areas (see [[Caching]]), but otherwise the separation of the application layers is complete enough to make this kind of clustering feasible. Similarly, the database could be a cluster of servers (e.g. a MySQL cluster), but this is not an easy task and you should seek expert support, e.g. from a Moodle Partner.

On very large, load-balanced, systems the performance of the shared components become critical. It's important that your shared file areas are properly tuned and that you use an effective cache (Redis is highly recommended). A good understanding of these areas of system administration should be considered a minimum requirement.

===Server cluster===

Using Moodle forum discussions:

*[http://moodle.org/mod/forum/discuss.php?d=57202 Moodle clustering]
*[http://moodle.org/mod/forum/discuss.php?d=44470 Software load balancing]
*[http://moodle.org/mod/forum/discuss.php?d=49986 TCP load balancing]
*[http://moodle.org/mod/forum/discuss.php?d=88214 Installation for 3000 simultaneous users]

==Hardware configuration==
'''Note''': The fastest and most effective change that you can make to improve performance is to '''increase the amount of RAM on your web server''' - get as much as possible (e.g. 4GB or more). Increasing primary memory will reduce the need for processes to swap to disk and will enable your server to handle more users.
* Better performance is gained by obtaining the best '''processor capability''' you can, i.e. dual or dual core processors. A modern BIOS should allow you to enable hyperthreading, but check if this makes a difference to the overall performance of the processors by using a [http://en.wikipedia.org/wiki/Super_PI CPU benchmarking tool].
* If you can afford them, use '''SCSI hard disks''' instead of SATA drives. SATA drives will increase your system's CPU utilization, whereas SCSI drives have their own integrated processors and come into their own when you have multiple drives. If you must have SATA drives, check that your motherboard and the drives themselves support NCQ (Native Command Queuing).
* Purchase hard disks with a '''low seek time'''. This will improve the overall speed of your system, especially when accessing Moodle's reports.
* Size your '''swap file''' correctly. The general advice is to set it to 4 x physical RAM.
* Use a '''RAID disk system'''. Although there are many different RAID configurations you can create, the following generally works best:
** install a hardware RAID controller (if you can)
** the operating system and swap drive on one set of disks configured as RAID-1.
** Moodle, Web server and Database server on another set of disks configured as RAID-5.
* If your 'moodledata' area is going to be on relatively slow storage (e.g. NFS mount on to a NAS device) you will probably have performance issues with the default cache configuration (which writes to this storage). See the page on [[Caching]] and consider an alternative. Using [https://en.wikipedia.org/wiki/GlusterFS GlusterFS] / [https://en.wikipedia.org/wiki/OCFS2 OCFS2] / [https://en.wikipedia.org/wiki/GFS2 GFS2] on a [https://en.wikipedia.org/wiki/Storage_Area_Network SAN] device and [https://en.wikipedia.org/wiki/Fibre_Channel Fiber Channel] could improve performance (See more info on the Moodle [https://moodle.org/mod/forum/discuss.php?d=214680#p1123124 forum thread], [https://moodle.org/mod/forum/discuss.php?d=310501#p1242382 NFS performance tuing] )
* Use '''gigabit ethernet''' for improved latency and throughput. This is especially important when you have your webserver and database server separated out on different hosts.
* Check the settings on your '''network card'''. You may get an improvement in performance by increasing the use of buffers and transmit/receive descriptors (balance this with processor and memory overheads) and off-loading TCP checksum calculation onto the card instead of the OS.
* Read this [http://moodle.org/mod/forum/discuss.php?d=68579 Case Study] on a server stress test with 300 users.
* See this [http://elearning.sgu.ac.jp/doc/PT/ accompanying report] on network traffic and server loads.
* Also see this SFSU presentation at Educause (using VMWare): [http://www.educause.edu/Resources/AnOpenSourceLMSforaMissionCrit/162843]

==Operating System==
* You can use [http://en.wikipedia.org/wiki/Linux Linux](recommended), Unix-based, Windows or Mac OS X for the server '''operating system'''. *nix operating systems generally require less memory than Mac OS X or Windows servers for doing the same task as the server is configured with just a shell interface. Additionally Linux does not have licensing fees attached, but can have a big learning curve if you're used to another operating system. If you have a large number of processors running SMP, you may also want to consider using a highly tuned OS such as [http://en.wikipedia.org/wiki/Solaris_Operating_Environment Solaris].
* Check your own OS and '''vendor specific instructions''' for optimization steps.
** For Linux look at the [http://linuxperf.sourceforge.net/ Linux Performance Team] site.
** For Linux investigate the hdparm command, e.g. hdparm -m16 -d1 can be used to enable read/write on multiple sectors and DMA. Mount disks with the [https://moodle.org/mod/forum/discuss.php?d=310501#p1242382 "async" and "noatime"] options.
** For Windows set the sever to be optimized for network applications (Control Panel, Network Connections, LAN connection, Properties, File & Printer Sharing for Microsoft Networks, Properties, Optimization). You can also search the [http://technet.microsoft.com/ Microsoft TechNet site] for optimization documents.

==Web server performance==

Installing [http://www.mozilla.com/en-US/ Firefox] and the [https://addons.mozilla.org/en-US/firefox/addon/1843 firebug] extension will allow you to watch the time it takes for each page component to load. Also, the [https://addons.mozilla.org/en-US/firefox/addon/5369 Yslow] extension will evaluate your page against Yahoo's [http://www.skrenta.com/2007/05/14_rules_for_fast_web_pages_by_1.html 14 rules], full text [http://developer.yahoo.com/performance/rules.html Best Practices for Speeding Up Your Web Site], <strike>([http://video.yahoo.com/video/play?vid=1040890 video])</strike> for fast loading websites.

===PHP performance===
* You are strongly recommended to use a '''PHP accelerator''' to ease CPU load, such as [http://pecl.php.net/apc APC], [http://www.php-accelerator.co.uk/ PHPA], [http://trac.lighttpd.net/xcache/ Xcache], [http://sourceforge.net/projects/wincache WinCache] or [http://eaccelerator.net/ eAccelerator]. (Take care to choose a PHP accelerator that is known to work well with your version of PHP and note that Turck MMCache is [http://turckmmcache.exeprod.com/TheManifestoEnglish no longer maintained] and can cause failures with PHP 5). PHP 5.5 (and newer) includes OpCache and is fully supported and recommended by Moodle
* Improvements in read/write performance can be improved by putting the cached PHP pages on a [[TMPFS]] filesystem - but remember that you'll lose the cache contents when there is a power failure or the server is rebooted.
* Performance of PHP is better when installed as an '''Apache/IIS6 ISAPI module''' (rather than a CGI). IIS 7.0/7.5 (Windows Server 2008/R2) users should choose a FastCGI installation for best performance.
* Also check the '''memory_limit''' in php.ini, reduce it to 16M for Moodle version earlier than 1.7 ([http://moodle.org/mod/forum/discuss.php?d=39656 See this forum discussion]). For Moodle 1.7 or later, it is recommended that the value of memory_limit should be 40M. As of [http://www.php.net/ChangeLog-5.php PHP 5.2.1] the default value for the memory_limit directive is 128M.
* Also see [[PHP_settings_by_Moodle_version]]
* Use [http://blog.bitnami.com/2014/06/performance-enhacements-for-apache-and.html PHP-FPM] (with apache).

===Install HowTo===
==== APC ====
* [http://2bits.com/articles/installing-php-apc-gnulinux-centos-5.html APC on CentOS 5.x (linux)]
* [http://fplanque.com/dev/linux/install-apc-php-cache-debian-lenny APC on Debian (linux)]
==== eAccelerator ====
* [http://noveckg.blogspot.com/2010/02/installing-eaccelerator-cache-for-php.html Installing eAccelerator on CentOS 5.x (linux)]
* [https://docs.moodle.org/en/Installing_eAccelerator_In_Ubuntu_Server/ Installing eAccelerator on Ubuntu Server (linux)]
==== MemCached ====
Memcached server (daemon)
* [https://www.tecmint.com/install-memcached-on-centos-7/ Installing Memcached on CentOS 7.x (linux)] (as of php 7.x, only memcached is available)
* [https://www.digitalocean.com/community/tutorials/how-to-install-and-secure-memcached-on-centos-7 How To Install and Secure Memcached on CentOS 7]
* [https://wiki.zimbra.com/wiki/Blocking_Memcached_Attack#Iptables_rules_for_Redhat_based_servers Iptables rules for Redhat based servers]
Memcached PHP 7.1 extension
* [https://dl.iuscommunity.org/pub/ius/stable/CentOS/7/x86_64/repoview/php71u-pecl-memcached.html php71u-pecl-memcached] from IUS CentOS 7.x repository.

===Apache performance===
* If you are using Apache on a Windows server, use the build from [http://www.apachelounge.com Apache Lounge] which is reported to have [http://moodle.org/mod/forum/discuss.php?d=93358 performance and stability improvements] compared to the official Apache download. Note that this is an unofficial build, so may not keep up with official releases.
* Set the '''MaxRequestWorkers''' directive correctly ('''MaxClients''' before Apache 2.4). Use this formula to help (which uses 80% of available memory to leave room for spare):
MaxRequestWorkers = Total available memory * 80% / Max memory usage of apache process
:Memory usage of apache process is usually 10MB but Moodle can easily use up to 100MB per process, so a general rule of thumb is to divide your available memory in megabytes by 100 to get a conservative setting for MaxClients. You are quite likely to find yourself lowering the MaxRequestWorkers from its default of 150 on a Moodle server. To get a more accurate estimate read the value from the shell command:
#ps -ylC httpd --sort:rss

:If you need to increase the value of '''MaxRequestWorkers''' beyond 256, you will also need to set the '''ServerLimit''' directive.

:'''Warning''': Do not be tempted to set the value of MaxRequestWorkers higher than your available memory as your server will consume more RAM than available and start to swap to disk.
* Consider reducing the '''number of modules''' that Apache loads in the httpd.conf file to the minumum necessary to reduce the memory needed.
* Use the '''latest version of Apache''' - Apache 2 has an improved memory model which reduces memory usage further.
* For Unix/Linux systems, consider lowering '''MaxConnectionsPerChild''' ('''MaxRequestsPerChild''' before Apache 2.4) in httpd.conf to as low as 20-30 (if you set it any lower the overhead of forking begins to outweigh the benefits).
* For a heavily loaded server, consider setting '''KeepAlive Off''' (do this only if your Moodle pages do not contain links to resources or uploaded images) or lowering the '''KeepAliveTimeout''' to between 2 and 5. The default is 15 (seconds) - the higher the value the more server processes will be kept waiting for possibly idle connections. A more accurate value for KeepAliveTimeout is obtained by observing how long it takes your users to download a page. After altering any of the KeepAlive variables, monitor your CPU utilization as there may be an additional overhead in initiating more worker processes/threads.
* As an alternative to using KeepAlive Off, consider setting-up a '''Reverse Proxy server''' infront of the Moodle server to cache HTML files with images. You can then return Apache to using keep-alives on the Moodle server.
* If you do not use a .htaccess file, set the '''AllowOverride''' variable to AllowOverride None to prevent .htaccess lookups.
* Set '''DirectoryIndex''' correctly so as to avoid content-negotiation. Here's an example from a production server:
DirectoryIndex index.php index.html index.htm
* Unless you are doing development work on the server, set '''ExtendedStatus Off''' and disable mod_info as well as mod_status.
* Leave '''HostnameLookups Off''' (as default) to reduce DNS latency.
* Consider reducing the value of '''TimeOut''' to between 30 to 60 (seconds).
* For the '''Options directive''', avoid Options Multiviews as this performs a directory scan. To reduce disk I/O further use
Options -Indexes FollowSymLinks

* Compression reduces response times by reducing the size of the HTTP response
# Install and enable mod_deflate - refer to documentation or man pages
# Add this code to the virtual server config file within the <directory> section for the root directory (or within the .htaccess file if AllowOverrides is On):
<ifModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/x-js text/javascript text/css application/javascript
</ifmodule>
* Use Apache [http://blog.bitnami.com/2014/06/performance-enhacements-for-apache-and.html event] [http://httpd.apache.org/docs/current/mpm.html MPM] (and not the default Prefork or Worker)

===IIS performance===
All alter this location in the registry:
HKLM\SYSTEM\CurrentControlSet\Services\Inetinfo\Parameters\
* The equivalent to KeepAliveTimeout is '''ListenBackLog''' (IIS - registry location is HKLM\ SYSTEM\ CurrentControlSet\ Services\ Inetinfo\ Parameters). Set this to between 2 to 5.
*Change the '''MemCacheSize''' value to adjust the amount of memory (Mb) that IIS will use for its file cache (50% of available memory by default).
*Change the '''MaxCachedFileSize''' to adjust the maximum size of a file cached in the file cache in bytes. Default is 262,144 (256K).
*Create a new DWORD called '''ObjectCacheTTL''' to change the length of time (in milliseconds) that objects in the cache are held in memory. Default is 30,000 milliseconds (30 seconds).

===Lighttpd, NginX and Cherokee performance===
You can increase server performance by using a '''light-weight''' webserver like [http://www.lighttpd.net/ lighttpd], [http://nginx.net/ nginx] or [http://www.cherokee-project.com/ cherokee] in combination with PHP in FastCGI-mode. Lighttpd was originally created as a proof-of-concept[http://www.lighttpd.net/story] to address the [http://www.kegel.com/c10k.html C10k problem] and while primarily recommended for memory-limited servers, its design origins and asynchronous-IO model make it a suitable and proven[http://blog.lighttpd.net/articles/2006/12/28/lighttpd-powers-5-alexa-top-250-sites] alternative HTTP server for high-load websites and web apps, including Moodle. See the [[lighttpd | MoodleDocs Lighttpd page]] for additional information, configuration example and links.

Alternatively, both [http://www.lighttpd.net/ lighttpd] and [http://nginx.net/ nginx] are capable of performing as a load-balancer and/or reverse-proxy to alleviate load on back-end servers[http://www.linuxjournal.com/article/10108], providing benefit without requiring an actual software change on existing servers.

Do note that these are likely to be the least tested server environments of all particularly if you are using advanced features such as web services and/or Moodle Networking. They are probably best considered for heavily used Moodle sites with relatively simple configurations.

===X-Sendfile===

X-Sendfile modules improve performance when sending large files from Moodle. It is recommended to configure your web server and Moodle to use this feature of available.

Configure web server:
* Apache - https://tn123.org/mod_xsendfile/
* Lighttpd - http://redmine.lighttpd.net/projects/lighttpd/wiki/X-LIGHTTPD-send-file
* Nginx - http://wiki.nginx.org/XSendfile

Enable support in config.php (see config-dist.php):
<code php>
// $CFG->xsendfile = 'X-Sendfile'; // Apache {@see https://tn123.org/mod_xsendfile/}
// $CFG->xsendfile = 'X-LIGHTTPD-send-file'; // Lighttpd {@see http://redmine.lighttpd.net/projects/lighttpd/wiki/X-LIGHTTPD-send-file}
// $CFG->xsendfile = 'X-Accel-Redirect'; // Nginx {@see http://wiki.nginx.org/XSendfile}
</code>

Configure file location prefixes if your server implementation requires it:
<code php>
// $CFG->xsendfilealiases = array(
// '/dataroot/' => $CFG->dataroot,
// '/cachedir/' => '/var/www/moodle/cache', // for custom $CFG->cachedir locations
// '/localcachedir/' => '/var/local/cache', // for custom $CFG->localcachedir locations
// '/tempdir/' => '/var/www/moodle/temp', // for custom $CFG->tempdir locations
// '/filedir' => '/var/www/moodle/filedir', // for custom $CFG->filedir locations
// );
</code>

==Database performance==

===MySQL performance===

The following are MySQL specific settings which can be adjusted for better performance in your my.cnf (my.ini in Windows). The file contains a list of settings and their values. To see the current values use these commands
SHOW STATUS;
SHOW VARIABLES;
'''Important''': You must make backups of your database before attempting to change any MySQL server configuration. After any change to the my.cnf, restart mysqld.

If you are able, the [http://mysqltuner.com/ MySQLTuner] tool can be run against your MySQL server and will calculate appropriate configuration values for most of the following settings based on your current load, status and variables automatically.

* Enable the '''query cache''' with
query_cache_type = 1.
For most Moodle installs, set the following:
query_cache_size = 36M
query_cache_min_res_unit = 2K.
The query cache will improve performance if you are doing few updates on the database.
* Set the '''table cache''' correctly. For Moodle 1.6 set
table_cache = 256 #(table_open_cache in MySQL > 5.1.2)
(min), and for Moodle 1.7 set
table_cache = 512 #(table_open_cache in MySQL > 5.1.2)
(min). The table cache is used by all threads (connections), so monitor the value of opened_tables to further adjust - if opened_tables > 3 * table_cache(table_open_cache in MySQL > 5.1.2) then increase table_cache upto your OS limit. Note also that the figure for table_cache will also change depending on the number of modules and plugins you have installed. Find the number for your server by executing the mysql statement below. Look at the number returned and set table_cache to this value.
mysql>SELECT COUNT(table_name) FROM information_schema.tables WHERE table_schema='yourmoodledbname';
* Set the '''thread cache''' correctly. Adjust the value so that your thread cache utilization is as close to 100% as possible by this formula:
thread cache utilization (%) = (threads_created / connections) * 100
* The '''key buffer''' can improve the access speed to Moodle's SELECT queries. The correct size depends on the size of the index files (.myi) and in Moodle 1.6 or later (without any additional modules and plugins), the recommendation for this value is key_buffer_size = 32M. Ideally you want the database to be reading once from the disk for every 100 requests so monitor that the value is suitable for your install by adjusting the value of key_buffer_size so that the following formulas are true:
key_read / key_read_requests < 0.01
key_write / key_write_requests <= 1.0
* Set the '''maximum number of connections''' so that your users will not see a "Too many connections" message. Be careful that this may have an impact on the total memory used. MySQL connections usually last for milliseconds, so it is unusual even for a heavily loaded server for this value to be over 200.
* Manage '''high burst activity'''. If your Moodle install uses a lot of quizzes and you are experiencing performance problems (check by monitoring the value of threads_connected - it should not be rising) consider increasing the value of back_log.
* '''Optimize your tables weekly and after upgrading Moodle'''. It is good practice to also optimize your tables after performing a large data deletion exercise, e.g. at the end of your semester or academic year. This will ensure that index files are up to date. Backup your database first and then use:
mysql>CHECK TABLE mdl_tablename;
mysql>OPTIMIZE TABLE mdl_tablename;
:The common tables in Moodle to check are mdl_course_sections, mdl_forum_posts, mdl_log and mdl_sessions (if using dbsessions). Any errors need to be corrected using REPAIR TABLE (see the [http://dev.mysql.com/doc/refman/5.0/en/repair-table.html MySQL manual] and this [http://moodle.org/mod/forum/discuss.php?d=58208#p279638 forum script]).
* '''Maintain the key distribution'''. Every month or so it is a good idea to stop the mysql server and run these myisamchk commands.
#myisamchk -a -S /pathtomysql/data/moodledir/*.MYI
:'''Warning''': You must stop the mysql database process (mysqld) before running any myisamchk command. If you do not, you risk data loss.
* Reduce the number of '''temporary tables saved to disk'''. Check this with the created_tmp_disk_tables value. If this is relatively large (>5%) increase tmp_table_size until you see a reduction. Note that this will have an impact on RAM usage.

===PostgreSQL performance===

There are some good papers around on tuning PostgreSQL (like [http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server this one]), and Moodle's case does not seem to be different to the general case.

The first thing to recognise is that if you really need to worry about tuning you should be using a separate machine for the database server. If you are not using a separate machine then the answers to many performance questions are substantially muddied by the memory requirements of the rest of the application.

You should probably '''enable autovacuum''', unless you know what you are doing. Many e-learning sites have predictable periods of low use, so disabling autovacuum and running a specific vacuum at those times can be a good option. Or perhaps leave autovacuum running but do a full vacuum weekly in a quiet period.

Set '''shared_buffers''' to something reasonable. For versions up to 8.1 my testing has shown that peak performance is almost always obtained with buffers < 10000, so if you are using such a version, and have more than 512M of RAM just set shared_buffers to 10,000 (8MB).

The buffer management had a big overhaul in 8.2 and "reasonable" is now a much larger number. I have not conducted performance tests with 8.2, but the recommendations from others are generally that you should now scale shared_buffers much more with memory and may continue to reap benefits even up to values like 100,000 (80MB). Consider using 1-2% of system RAM.

PostgreSQL will also assume that the operating system is caching its files, so setting '''effective_cache_size''' to a reasonable value is also a good idea. A reasonable value will usually be (total RAM - RAM in use by programs). If you are running Linux and leave the system running for a day or two you can look at 'free' and under the 'cached' column you will see what it currently is. Consider taking that number (which is kB) and dividing it by 10 (i.e. allow 20% for other programs cache needs and then divide by 8 to get pages). If you are not using a dedicated database server you will need to decrease that value to account for usage by other programs.

Some other useful parameters that can have positive effects, and the values I would typically set them to on a machine with 4G RAM, are:

work_mem = 10240

That's 10M of RAM to use instead of on-disk sorting and so forth. That can give a big speed increase, but it is per connection and 200 connections * 10M is 2G, so it can theoretically chew up a lot of RAM.

maintenance_work_mem = 163840

That's 160M of RAM which will be used by (e.g.) VACUUM, index rebuild, cluster and so forth. This should only be used periodically and should be freed when those processes exit, so I believe it is well worth while.

wal_buffers = 64

These buffers are used for the write-ahead log, and there have been a number of reports on the PostgreSQL mailing lists of improvement from this level of increase.

This is a little out of date now (version 8.0) but still worth a read: http://www.powerpostgresql.com/Docs

And there is lots of good stuff here as well: http://www.varlena.com/GeneralBits/Tidbits/index.php

''Based on Andrew McMillan's post at [http://moodle.org/mod/forum/discuss.php?d=68558 Tuning PostgreSQL] forum thread.''

* Splitting '''mdl_log''' to several tables and using a VIEW with UNION to read them as one. (See Tim Hunt [https://moodle.org/mod/forum/discuss.php?d=243531#p1104165 explanation] on the Moodle forums)

===Other database performance links===
* Consider using a '''distributed cacheing system''' like [http://en.wikipedia.org/wiki/Memcached memcached] but note that memcached does not have any security features so it should be used behind a firewall.
* Consider using PostgreSQL. See [[Arguments in favour of PostgreSQL]] and [http://moodle.org/mod/forum/discuss.php?d=49195 how to migrate from MySQL to PostgreSQL] (forum discussion).
* [http://dev.mysql.com/doc/refman/5.0/en/server-parameters.html General advice on tuning MySQL parameters] (advice from the MySQL manual)
* [http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/ InnoDB performance optimization] taken from the [http://www.mysqlperformanceblog.com/ MySQL performance blog] site.

==Performance of different Moodle modules==

Moodle's activity modules, filters, and other plugins can be activated/deactivated. If necessary, you may wish to deactivate some features (such as chat) if not required - but this isn't necessary. Some notes on the performance of certain modules:

* The '''Chat''' module is [http://moodle.org/mod/forum/discuss.php?d=37979&parent=175079 said] to be a hog in terms of frequent HTTP requests to the main server. This can be reduced by setting the module to use ''Streamed'' updates, or, if you're using a Unix-based webserver, by running the chat in daemon mode. When using the Chat module use the configuration settings to tune for your expected load. Pay particular attention to the ''chat_old_ping'' and ''chat_refresh'' parameters as these can have greatest impact on server load.
* The Moodle '''Cron''' task is triggered by calling the script ''cron.php''. If this is called over HTTP (e.g. using wget or curl) it can take a large amount of memory on large installations. If it is called by directly invoking the php command (e.g. ''php -f /path/to/moodle/directory/admin/cli/cron.php'') efficiency can be much improved.
* The '''Recent activities''' block is consuming too many resources if you have huge number of records <code>mdl_log</code>. This is being tested to optimize the SQL query.
* The '''Quiz''' module is known to stretch database performance. However, it has been getting better in recent versions, and we don't know of any good, up-to-date performance measurements. (Here is a [http://moodle.org/mod/forum/discuss.php?d=68579 case study from 2007 with 300 quiz users].). The following suggestions were described by [https://moodle.org/user/view.php?id=94615&course=5 Al Rachels] in [https://moodle.org/mod/forum/discuss.php?d=347126 this forum thread]:
** make sure both Moodle, and the operating system, are installed on a [https://en.wikipedia.org/wiki/Solid-state_drive solid state drive]
** upgrade to and use [https://docs.moodle.org/dev/Moodle_and_PHP7 PHP 7]
** run MySQLTuner and implement its recommendations

See [[Performance settings]] for more information on performance-related Moodle settings.

==See also==

*Using Moodle: [http://moodle.org/mod/forum/view.php?f=94 Hardware and Performance] forum
*[http://opensourceelearning.blogspot.be/2012/10/why-your-moodle-site-is-slow-five.html Why Your Moodle Site is Slow: Five Simple Settings] blog post from Jonathan Moore
*I teach with Moodle perfomance testing: http://www.iteachwithmoodle.com/2012/11/17/moodle-2-4-beta-performance-test-comparison-with-moodle-2-3/
*[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.2 performance and MUC APC cahe store]
*[http://jfilip.ca/2013/09/25/moodle-performance-testing-2-4-6-vs-2-5-2-vs-2-6dev/ Moodle performance testing 2.4.6 vs 2.5.2 vs 2.6dev]
*[http://jfilip.ca/2013/09/24/moodle-performance-analysis-revisted-now-with-mariadb/ Moodle performance analysis revisited (now with MariaDB)]
*[http://tjhunt.blogspot.ca/2013/05/performance-testing-moodle.html Tim Hunt's blog (May 2, 2013) on performance testing Moodle]
*[http://newrelic.com/ New Relic, Application Performance Monitoring]
*[http://blog.bitnami.com/2014/06/performance-enhacements-for-apache-and.html Performance enhacements for Apache and PHP (Apache Event MPM and PHP-FPM)]
*[https://scholarlms.net/performance-recommendations/ Performance recommendations]

There have been a lot of discussions on moodle.org about performance, here are some of the more interesting and (potentially) useful ones:

* [http://moodle.org/mod/forum/discuss.php?d=83057 Performance woes!]
* [http://moodle.org/mod/forum/discuss.php?d=57028 Performance perspectives - a little script]
* [http://moodle.org/mod/forum/discuss.php?d=88927 Comments on planned server hardware]
* [http://moodle.org/mod/forum/discuss.php?d=102978#p461624 Moodle performance in a pil by Martin Langhoff]
* [https://moodle.org/mod/forum/discuss.php?d=240391#unread Advice on optimising php/db code in moodle2+]
* [https://moodle.org/mod/forum/discuss.php?d=243531 Moodle 2.5 performance testing at the OU]
* [https://moodle.org/mod/forum/discuss.php?d=273602 100 active users limit with 4vCPU]
* [https://moodle.org/mod/forum/discuss.php?d=336603#p1356423 Performance Tip ... shared...]

[[es:Recomendaciones sobre desempeño]]
[[fr:Performance]]
[[ja:パフォーマンス]]
[[de:Geschwindigkeitsempfehlungen]]

File upload size

2019-08-01T14:27:47Z

Howardsmiller: /* Restricting the File size - how it works */

{{Installing Moodle}}
==Upload file size restrictions==

Probably the most frequently asked question on moodle.org is "How do I increase the upload file size limit?" The changes that need be made are the same in all versions of Moodle, just in different OS' they need be made in different places. Upload file sizes are restricted in a number of ways and each one in this list restricts the following ones:

# Server level
# Moodle site level
# Course level
# Activity level

This is a contentious issue, mainly because you might think that it should be set inside the Moodle. Unfortunately, this is not so, these are environment issues that need to be set in the server and PHP folders, Moodle cannot work outside itself.

==Physical access to Server==
These instructions assume you have full physical and administrative access to your server. If you are using a hosted server then you will probably need to look into other ways to increase your file upload size.

There are positives and negatives to both methods below. If you modify the php.ini file then the changes will effect all php applications on your server. Since PHP5 you can only have one php.ini file on your server. The php.ini method will work with all web servers though. The .htaccess method will only effect the folder and all subfolders that it is placed in, but you must have certain settings enabled in Apache.

==Restricting the File size - how it works==
The Host may set a limit on the maximum file upload size in the Server environment, which you may override if the Host allows you to. PHP has a setting that it uses to limit the size of the file that it handles in upload. The Host has set that figure in the php.ini based on their particular perceptions and their clientele need. This size appears in Moodle in the '''Site administration > Security > Site security settings > Maximum uploaded file size''' drop-down combo box. You can change this at any time to suit your site need. In the Course Settings page, there is also a further restriction that can be made. At no time can the Course setting over-ride the Site setting, nor can the Site setting over-ride the php.ini setting, which cannot over-ride the Server setting. The only exception to this rule is that you can manipulate both the Server and the PHP settings, and how to do that is described below.

==Modifying the php.ini file==
These instructions show you how to change the file upload size by editing your php.ini file.

For the most part these instructions amount to the following.
In the file /etc/php5/apache2/php.ini you need to change "post_max_size", "upload_max_filesize" and "max_execution_time" to values that suit your needs using whatever editor you are used to.

Below are some line by line instructions for various installations of Moodle.

====Ubuntu Linux Instructions====

These instructions assume that you have installed the standard Moodle package, PHP 5 and Apache 2 via apt-get and left it all as a default install. If you have compiled yourself I presume that you will know where your php.ini files are!

You need to edit the following three settings in your php.ini file located at: /etc/php5/apache2/
Here are a set of instructions to follow line by line.

*Type "sudo nano /etc/php5/apache2/php.ini"
*Press Ctrl and W and type "post_max_size"
*Change the value to the number of Mb you want your site to accept as uploads
*Press Ctrl and W and type "upload_max_filesize"
*Change the value to the number of Mb you want your site to accept as uploads
*Press Ctrl and W and type "max_execution_time"
*Change the value to 600
*Press Ctrl and O
*Press Ctrl and X
*Type sudo apachectl restart

[http://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size NGINX] system administrators should also add "client_max_body_size XXXm;" to the "http" section of their nginx main configuration file. ([https://rtcamp.com/tutorials/php/increase-file-upload-size-limit/#change-in-nginx-config see more info]) if you have SSL, that will require you to set the above for the SSL ''server'' and ''location'' too.

Your new file size limit should now appear in Administration > Security > Site Policies > Maximum uploaded file size

====XAMPP on Mac Instructions====

These are instructions for how to do this for Moodle on a Mac using the [http://download.moodle.org/macosx/ XAMPP sample download package available]. (This is not for a OS X production server.)

* Close down Apache and MySQL if they are running via the XAMPP Control app and close the XAMPP Control app
* Open Finder and go to Applications
* Navigate down and open the folder ''XAMPP'' / ''xamppfiles'' / ''etc''
* Open the file ''php.ini'' with TextEdit (or another plain text editor)
* Search for the ''post_max_size'' setting and up this from 128M (the default) to more; 500M is the maximum
* Do the same for ''upload_max_filesize'' (make the numbers the same)
* Search for the ''max_execution_time'' setting and up this to 300 (or more if you get timeouts on uploads)
* Save the php.ini file
* restart Apache and MySQL as usual

Note: You may get a "permission denied" error when saving the php.ini file unless you are logged in with admin access to your Mac. To work around this, you can set the ''/etc'' directory in which the php.ini file is located to be writable temporarily. For how to do that, see [http://answers.yahoo.com/question/index?qid=20090115235753AA4DtJ0 here] or [http://www.ehow.com/how_2314896_fix-permissions-mac-os-x.html here].

====Windows XP and Server 2003 Instructions====

These instructions presume that you have downloaded the latest PHP 5.3.x Windows zip package and extracted it to C:\PHP. If you have installed PHP to another location then change all references to "C:\PHP" to the location you installed PHP too.
{| class="nicetable"
|[[Image:lightbulb.png]]
|Download and install any text editor that can save the file in a UTF-8 format, [http://www.crimsoneditor.com Crimson Editor] is one such, NotePad++ is another, use that instead of either Wordpad or Notepad! The issue is that WordPad or Notepad will include hidden characters that may not be compatible with the requirements of PHP.
|}

*Open C:\PHP
*Right Click the '''php.ini''' file in this folder and choose "Open with..." selecting your editor of choice.
*Press Ctrl + F and type "post_max_size" (click Find...", where needed)
*Change the value to the number of Mb you want your site to accept as uploads
*Press Ctrl + F and type "upload_max_filesize" (click Find...", where needed)
*Change the value to the number of Mb you want your site to accept as uploads
*Press Ctrl + F and type "max_execution_time" (click Find...", where needed)
*Change the value to 600
*Press Ctrl and S or the save button.
*Exit your editor.
*Restart your webserver to reload PHP with the edited changes.
**'''For IIS'''
**Open the Start Menu on your server and select "Run"
**Type "iisreset /RESTART"
**For '''Apache 2 and Windows XP'''
**Go to Start > All Programs > Apache > Restart
**'''For Apache 2 and Windows Server'''
**The following command will work as long as you have installed Apache 2 as a service on your Windows Server
**Open your Start Menu on your server and select "Run"
**Type "httpd -k restart"

Your new file size limit should now appear in Administration > Security > Site Policies > Maximum uploaded file size

'''NOTE:''' These instructions also cover the Xampp Windows installer. Just replace C:\PHP with C:\Moodle\server\php and to restart your Moodle with a normal stop-start.

==Modifying the apache config file==
====Ubuntu Linux Instructions====
You may also need to edit the config.php file in the moodle directory:
*Type "gksudo nautilus" to get root permissions
*Navigate to /etc/moodle
*Open apache.conf
*Go to the "<IfModule mod_php5.c>" section
*Change "php_value upload_max_filesize = 2M" to a higher value
*Change "php_value post_max_size = 2M" to a higher value
*Go to the "<IfModule mod_php4.c>" section
*Change "php_value upload_max_filesize = 2M" to a higher value
*Change "php_value post_max_size = 2M" to a higher value
*Save file
*Type sudo /etc/init.d/apache2 restart

===Modifying the .htaccess file===

The following instructions will only work on an Apache web server, and also the Apache server must have Overrides allowed. Traditionally, you could only use .htaccess files when PHP was run as a module of Apache, but with Apache 2.2, this appears to no longer be the case. You can now use the .htaccess file in either module or cgi forms. As well, allowing the use of .htaccess files will cause a performance hit on the server, not a desirable outcome either - so check with your Host.

The .htaccess file is a distributed configuration file, that is, it can be used on a per-folder basis to configure each user's folder and sub-folders. You cannot alter the "AllowOverrides" directive in the Apache configuration file with a .htaccess file, only the Host can set that manually. Usually the Host will place a .htaccess file into your site Root if they do allow you to override the server settings. You can edit it the same as below, and the overrides you set will work. Alternatively, you may create your own .htaccess file in your text editor. It may also be called something else, like .config. If you have any file that starts with a ., you might want to open it in your text editor, just out of curiosity.

Create a file called .htaccess in Moodle's main directory (where 'index.php' is located, not the 'moodledata' directory) that contains the following information:

php_value upload_max_filesize 20971520
php_value post_max_size 20971520
php_value max_execution_time 600

20971520 is the integer value for 20Mb. You can use the following site to [http://www.onlineconversion.com/computer_base2.htm convert MegaBytes to Bytes].

For a more complete description of how to edit the .htacess file, look at this page, [http://httpd.apache.org/docs/current/howto/htaccess.html Apache Tutorial: .htaccess files]

===Modifying the IIS 7.0/7.5 configuration (Windows Server 2008, Windows Server 2008 R2)===
First increase activity and request time outs (allows large files to succeed on slow connections)
FastCGI Settings > Edit (Right-click on PHP application)
Set Process Model > Activity Timeout to '3600' (one hour)
Set Process Model > Request Timeout to '3600' (one hour)
Next set 'Maximum allowed content length'
Request Filtering > Edit Feature Settings:
Set 'Maximum allowed content length' to your desired file size (in bytes) e.g. '536870912' for 512MB (default is approximately 28.6MB)

==Hosted Server==
Things can be a little different with a hosted server for uploaded and downloaded file size. You are probably going to to be told to create or change a .htaccess file, or to modify a php.ini file.

{| class="nicetable"
|[[Image:lightbulb.png]]
|It might be a good idea to talk to with your service provider before you attempt anything. They probably have instructions on "how to" and may have their own limits for uploaded file size. Some hosts measure the file size in gigabytes and others in megabytes. If you are unhappy with their limits, then check your contract and consider changing your provider to one that has a limit and price that you like.
|}

===.htaccess with hosted server===
The one purpose of an .htaccess file is to override the the current limitations of both the server and the php.ini file. Your hosted server should inform you where that file needs be placed in your Moodle, but generally in the root is sufficient. They may already have a standard file you can use, if so, use it - but perhaps not.

To the .htaccess file add the lines:
php_value upload_max_filesize 128M
php_value post_max_size 128M

This will limit uploads to 128MB, but you can make it any size you agree with your provider. The wording may vary slightly, according to the demands of the server.

===php.ini with hosted server===
Some servers will not allow you to change the moodle root .htaccess file and tell you to use a php.ini file for php directives. Here you can use the instruction located in the section above called [[File_upload_size#Modifying_the_php.ini_file|Modifying the php.ini file]].

Find the php.ini file in your moodle subfolder on your hosted server. You might want to copy the file as a backup just in case. Edit php.ini, find "upload_max_filesize" and post_max_size in the code. After the = change the number. Here the max filesize is 20 megabytes.

upload_max_filesize = 20M
post_max_size = 20M

{| class="nicetable"
|[[Image:lightbulb.png]]
|Still not changed? Some hosts using cpanel have a php config program under services/software. Use the "Single php.ini" option and make sure you note the location of the php.ini file to modify. This changes the .htaccess file in the same area and thus the server limit for all programs using php.
|}

{| class="nicetable"
|[[Image:lightbulb.png]]
|Still not changed? [http://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size NGINX] system administrators should also add client_max_body_size XXXm; to the "http" section of their nginx main configuration file. ([https://rtcamp.com/tutorials/php/increase-file-upload-size-limit/#change-in-nginx-config see more info]) if you have SSL, that will require you to set the above for the SSL ''server'' and ''location'' too.
|}

==See Also==
*[[Administration_FAQ#How_do_the_limits_on_uploaded_files_work.3F|Administration FAQ Doc page]]
*[[Site_policies#Maximum_uploaded_file_size|Site Policies Doc page]]
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=39625 Detailed instructions to increase the maximum allowed size for uploaded files] forum discussion
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=97907 Instructions to increase maximum allowed size on hosted servers] forum discussion
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=124441 Help on changing the maximum upload size when installing Moodle via apt-get] forum discussion

[[es:Tamaño de archivo subido]]

[[Category:FAQ|File]]

Antivirus plugins

2019-03-27T21:23:36Z

Howardsmiller: /* See also */

{{Security}}
An administrator can enable and configure virus scanners for use on uploaded files via ''Site administration > Plugins > Antivirus plugins > Manage antivirus plugins''.

ClamAV antivirus is available as a standard plugin. It's likely that more antivirus plugins will be available in future from the [https://moodle.org/plugins/ Moodle plugins directory].

==ClamAV antivirus==

To make use of ClamAV antivirus, ClamAV® should be installed on your server. See http://www.clamav.net for more information.

== See also ==

* RHEL/CentOS and [https://en.wikipedia.org/wiki/Security-Enhanced_Linux SELinux]: https://moodle.org/mod/forum/discuss.php?d=316066
* RHEL/CentOS and [https://access.redhat.com/blogs/766093/posts/1976243 PrivateTmp]: https://moodle.org/mod/forum/discuss.php?d=364706
* Offboarding ClamScan from web nodes https://moodle.org/mod/forum/discuss.php?d=382731

[[Category:Site administration]]

[[eu:Antibirusa]]
[[de:Antivirus]]
[[es:Plugins antivirus]]

Antivirus plugins

2019-03-27T21:22:43Z

Howardsmiller: /* See also */

{{Security}}
An administrator can enable and configure virus scanners for use on uploaded files via ''Site administration > Plugins > Antivirus plugins > Manage antivirus plugins''.

ClamAV antivirus is available as a standard plugin. It's likely that more antivirus plugins will be available in future from the [https://moodle.org/plugins/ Moodle plugins directory].

==ClamAV antivirus==

To make use of ClamAV antivirus, ClamAV® should be installed on your server. See http://www.clamav.net for more information.

== See also ==

* RHEL/CentOS and [https://en.wikipedia.org/wiki/Security-Enhanced_Linux SELinux]: https://moodle.org/mod/forum/discuss.php?d=316066
* RHEL/CentOS and [https://access.redhat.com/blogs/766093/posts/1976243 PrivateTmp]: https://moodle.org/mod/forum/discuss.php?d=364706
* Offboarding ClamScan from web notes https://moodle.org/mod/forum/discuss.php?d=382731

[[Category:Site administration]]

[[eu:Antibirusa]]
[[de:Antivirus]]
[[es:Plugins antivirus]]

Antivirus plugins

2019-03-27T21:22:15Z

Howardsmiller: /* See also */

{{Security}}
An administrator can enable and configure virus scanners for use on uploaded files via ''Site administration > Plugins > Antivirus plugins > Manage antivirus plugins''.

ClamAV antivirus is available as a standard plugin. It's likely that more antivirus plugins will be available in future from the [https://moodle.org/plugins/ Moodle plugins directory].

==ClamAV antivirus==

To make use of ClamAV antivirus, ClamAV® should be installed on your server. See http://www.clamav.net for more information.

== See also ==

* RHEL/CentOS and [https://en.wikipedia.org/wiki/Security-Enhanced_Linux SELinux]: https://moodle.org/mod/forum/discuss.php?d=316066
* RHEL/CentOS and [https://access.redhat.com/blogs/766093/posts/1976243 PrivateTmp]: https://moodle.org/mod/forum/discuss.php?d=364706
* Offboarding ClamScan from web notes [https://moodle.org/mod/forum/discuss.php?d=382731]

[[Category:Site administration]]

[[eu:Antibirusa]]
[[de:Antivirus]]
[[es:Plugins antivirus]]

Upgrading

2018-12-10T14:19:52Z

Howardsmiller: Bad security advice sorted

{{Installing Moodle}}
''This page explains in detail how to upgrade Moodle. For a summary of the process, see [[Upgrade overview]].''

==Check the requirements==

Before upgrading, check that your server meets all requirements for {{Version}} in ''Administration > Site administration > Server > [[Environment]]''.

See the [{{Release notes}} release notes] in the dev docs for both [{{Release notes}}#Server_requirements server] and [{{Release notes}}#Client_requirements client] software requirements.

Notes:

* You can only upgrade to Moodle {{Version}} from Moodle 3.1 or later. If upgrading from earlier versions, you must [https://docs.moodle.org/31/en/Upgrading_to_Moodle_3.1 upgrade to 3.1] as a first step.

==Before upgrading==

'''We advise that you test the upgrade first on a COPY of your production site, to make sure it works as you expect.'''

Consider setting the [[Upgrade key|upgrade key]] for your site.

== Backup important data ==

There are three areas that should be backed up before any upgrade:
#Moodle software (For example, everything in server/htdocs/moodle)
#Moodle uploaded files (For example, server/moodledata)
#Moodle database (For example, your Postgres or MySQL database dump)

See [[Site backup]] for more specific information.

== Check for plugin updates ==

If you have [[Automatic updates deployment]] enabled, you will be able to update installed plugins automatically during the upgrade. Just make sure you check for available updates (via the button for it) at the Plugins check screen.

If you are updating plugins manually, it is a good moment now to check in the [http://moodle.org/plugins Moodle Plugins directory] whether there is a {{Version}} version available for any plugins (including themes) that you have previously installed on your site. If so, download the plugin package. In the next step, you will copy it to the appropriate location in your Moodle code (see [[Installing plugins]]).

The upgrade of the plugin will then happen as part of the Moodle upgrade process.

If an out-of-date plugin causes your upgrade to fail, you can usually delete the plugin code rather than uninstalling it from within Moodle so that the data associated with it is not deleted.

==Put your site into maintenance mode==
Before you begin upgrading your site, you should put it into [[Maintenance_mode | maintenance mode]] to stop any non-admin users from logging in. Then you should wait for any currently running cron processes to complete before proceeding.

== Install the new Moodle software ==
You can fetch the current version of the software through

wget http://sourceforge.net/projects/moodle/files/Moodle/stable{{Version2}}/moodle-latest-{{Version2}}.tgz

=== Standard install package ===

# Move your old Moodle software program files to another location. ''Do NOT copy new files over the old files.''
# Unzip or unpack the upgrade file so that all the new Moodle software program files are in the location the old files used to be in on the server. Moodle will adjust SQL and moodledata if it needs to in the upgrade.
# Copy your old [[Configuration file|config.php file]] back to the new Moodle directory.
# As mentioned above, if you had installed any plugins on your site you should add them to the new code tree (Moodle directory structure) now. It is important to check that you get the correct version for your new version of Moodle. Be particularly careful that you do not overwrite any code in the new version of Moodle and that you place the plugin folders in the correct directory (the same directory that they are in in the current installation.)
# Your moodledata folder should be located separately to your Moodle code folder and, as such, should not need anything done to it. Moodle 3.0 will throw a warning if it is located in a web accessible folder and the moodledata should never be located in the Moodle code folder. If you are moving your installation to a new server or new location on your server, then you will need to follow the Migration documents.

====Linux====
mv moodle moodle.backup
tar xvzf moodle-{{Version}}.tgz

Next, copy across your config.php, any custom plugins, and your .htaccess file if you created one ('''check that custom plugins are the correct version for your new Moodle first'''):

cp moodle.backup/config.php moodle
cp -pr moodle.backup/theme/mytheme moodle/theme/mytheme
cp -pr moodle.backup/mod/mymod moodle/mod/mymod

Don't forget to make moodle/config.php (and the rest of the source code) readable by your www server. For maximum security the files should not be writeable by your server. This is especially important on a 'production' server open to the public internet.

chown -R root:root moodle (Linux debian - or even create a user especially for moodle. '''Don't''' use the web server user, e.g. www-data)
chmod -R 755 moodle

If you use cron, take care that cron.php is executeable and uses the correct php command:
chmod 740 admin/cli/cron.php (some configurations need chmod 750 or chmod 755)
copy the first line from cron.php (if it looks like '#!/usr/local/bin/php' or '#!/usr/local/bin/php5.3', no need to copy '<?php')
if necessary. However, for a simple upgrade, there should be no need to change anything with cron.

=== Using Git ===

You can use Git for updating or upgrading your Moodle. See [[Git for Administrators]] for details.

===Command line upgrade===

On Linux servers, Moodle {{Version}} supports running the [[CLI|upgrade from the command line]], rather than through a web browser. This is likely to be more reliable, particularly for large sites.

== Finishing the upgrade ==

The last step is to trigger the upgrade processes within Moodle.

If you put your site into Maintenance mode earlier; take it out now!

To do this just go to ''Administration > Site administration > Notifications''.

Moodle will automatically detect the new version and perform all the SQL database or file system upgrades that are necessary. If there is anything it can't do itself (very rare) then you will see messages telling you what you need to do.

Assuming all goes well (no error messages) then you can start using your new version of Moodle and enjoy the new features!

Note: If you are running multiple servers then you should purge all caches manually (via ''Administration > Site administration > Development > Purge all caches'') after completing the upgrade on all servers.

===Fatal error: Maximum execution time of 30 seconds exceeded...===

If your server uses a main language other than English, you may encounter a 'Fatal error: Maximum execution time of 30 seconds exceeded' when you try to upgrade it. You can increase max_execution_time = 160 on php.ini to allow the scripts enough time to process the language update. Otherwise, you can switch to English as the default language before doing the upgrade and back to your original language after a succcessful upgrade. See the forum discussion at https://moodle.org/mod/forum/discuss.php?d=119598.

==After upgrading==

The config.php file from your installation should work fine but if you take a look at config-dist.php that came with Moodle 3.0 there are more/different options available (e.g. database drivers and settings). It's a good idea to map your old config.php settings to a new one based on the 3.0 config-dist.php.

===Cron===

Cron has received a major update (MDL-25499) and now has support for both scheduled and ad hoc tasks.

The benefits of these changes are:
* The schedule for every task can be configured by the admin
* Tasks can run in parallel
* Cron processes use locking to prevent the same task running at the same time by different processes
* Clusters with multiple identical application nodes are supported, you can run cron on all of them

A result of this is that cron can be run much more often, which means (for example) forum posts can be sent out sooner. To take advantage of the new cron system it is now strongly recommended that administrators increase the frequency that cron is run to at least ''once per minute''.

You also may need to modify any automated scripts you have that are parsing the output from cron. It is no longer possible to simply monitor the output of cron for the string "Cron script completed correctly" (if that is what you were doing). An alternative is to monitor the output for the string "task failed:". If you detect that a task is failing, [[Cron#Debugging_Scheduled_Tasks|here]] are some tips for debugging the failure.

Before the upgrade, there may have been a cron task that was failing, which was preventing the rest of cron from being executed. A failure in any single task will no longer prevent the rest of the Moodle cron tasks from executing, so you may uncover previously masked bugs. It is a good idea to closely monitor the output from cron after the upgrade.

===Assignments===

The old assignment (2.2) module has been removed from core and has been replaced by a stub to support transparently remapping URLs and restoring course backups from the old module to the new one.

If you are still using the old assignment (2.2) module, after upgrading to Moodle 3.0 all assignment (2.2) activities will be hidden. You need to run the [[Assignment upgrade tool]] to un-hide the activities.

If you really, really need to keep using the old assignment (2.2) module, you should update the code to Moodle 3.0, and then replace the "mod/assignment" folder with the one from https://github.com/moodlehq/moodle-mod_assignment/releases before completing the upgrade.

==Possible issues that may affect you in Moodle {{Version}}==

* Sites using a custom theme or login form must include a new login token field in the login form. See the dev docs [[:dev:Login token|Login token]] for details.
* To use 'Run now' links in [[Scheduled tasks]], you will need to set 'Path to PHP CLI' (pathtophp) in Site administration / Server / System paths.
* Adding another user as a messaging contact now requires approval from the other user. Any contacts that you have that aren't mutual (ie. both users have added each other as a contact) will be removed from your list of contacts.
* New setting 'Allow site-wide messaging' in Site administration / Advanced features. The setting is disabled by default (for new installs) but enabled for upgraded sites.
* The timeline tab in the course overview block is now in a separate block [[Timeline block|Timeline]]. There are also more new Dashboard blocks - [[Recently accessed courses block|Recently accessed courses]], [[Recently accessed items block|Recently accessed items]] and [[Starred courses block|Starred courses]].

''Please add more items...''

See also the list of [https://tracker.moodle.org/issues/?jql=project%20%3D%20mdl%20AND%20resolution%20%3D%20fixed%20AND%20fixVersion%20in%20(%223.6%22)%20AND%20labels%20%3D%20upgrade_notes upgrade_notes-labelled issues] and [https://tracker.moodle.org/issues/?jql=project%20%3D%20mdl%20AND%20resolution%20%3D%20fixed%20AND%20fixVersion%20in%20(%223.6%22)%20AND%20labels%20%3D%20ui_change%20 ui_change-labelled issues].

=== Moodle 3.1, 3.2, 3.3, 3.4 and 3.5 improvements ===

Depending on which version you are upgrading from, please see the section 'Possible issues that may affect you' in the documentation

* [https://docs.moodle.org/31/en/Upgrading Upgrading to Moodle 3.1]
* [https://docs.moodle.org/32/en/Upgrading Upgrading to Moodle 3.2]
* [https://docs.moodle.org/33/en/Upgrading Upgrading to Moodle 3.3]
* [https://docs.moodle.org/34/en/Upgrading Upgrading to Moodle 3.4]
* [https://docs.moodle.org/35/en/Upgrading Upgrading to Moodle 3.5]

==See also==

* [[Installation]]
* Using Moodle [http://moodle.org/mod/forum/view.php?id=28 Installation help forum]
* [[dev:Moodle {{Version}} release notes|Moodle {{Version}} release notes]]

[[es:Actualización de moodle]]
[[fr:Mise à jour]]
[[ja:Moodleをアップグレードする]]
[[de:Aktualisierung von Moodle]]

Feedback templates

2018-10-24T13:34:00Z

Howardsmiller: /* Save these questions as a new template */

{{Feedback}}
Within the Feedback Module you can create and re-use sets of Feedback questions using the Template tool.

The Templates tab provides the following template features:

==Use a template==

Previously saved Templates will be listed in this area and can be selected using the dropdown menu.

After selecting a Template, Moodle will display a preview of the Feedback questions contained within the Template and confirm Are you sure you want to use this template?

You will also be required to select one of two options:

;Delete old items
:Remove any questions/text types previously added to the Feedback Activity you are viewing before importing items from the selected Template

;Append new items
:Add items stored within the selected template to the current Feedback activity, to any existing questions/text types.

Once you have made your selection click Save changes to copy across the Feedback items or press Cancel to exit from the template copy process.

== Save these questions as a new template ==

After creating a new Feedback activity and populating it with questions, you can save it as a Template for re-use by yourself or others.

When saving a new Template enter a descriptive title in the Name field and choose whether you wish to make this Template available for use by others via the Public tickbox . A Public template may be viewed and re-used by users with appropriate access rights such as administrators and teacher/trainers. When a Public template is used as a basis for a new Feedback, the activity settings and questions within it may be edited by the teacher/trainer, however the original Template remains unchanged.

'''Note:''' To create public templates users must have the mod/feedback:createpublictemplate capability at the System/Site level. This will not be the case by default. You would either need to allow this capability in the 'Authenticated user' role or create a specific side-wide role for permitted users.

== Delete Template... ==

To remove a Template you have created or have appropriate permissions to edit, from your Moodle site, use the Delete template... link and click the delete icon next to the corresponding template name.

==Export Questions==

The Export Questions tool allows you to save the questions/text types within your Feedback Activity in .xml format. Clicking the Export questions link will prompt you to Save or Open this file.

==Import Questions==

Where you have previously exported and saved questions from a Feedback activity in .xml format, you can reimport them into a new Feedback activity.

The Import questions tool is particularly useful where you need to import questions from a different instance of Moodle and the Template tool is not applicable.

Tip: You can also use the Import/Export ability to combine multiple Imports from multiple templates; also it can be used to avoid creating duplicates when using Append.

After clicking on the Import questions link you will be prompted to select one of the following options:

;Delete old items
:The current questions and all your user's responses will be deleted within the current Feedback activity

;Append new items
:All old questions and the assigned values will be preserved within the current Feedback activity and the imported questions will be added to the existing questions.

Use the Choose a file button to navigate to the course Files area and upload and/or select the relevant .xml file. Once selected use the Import from this file button to import the questions or use Cancel to return to the Templates general tab.

[[de:Feedback-Vorlagen]]
[[es:Plantillas de retroalimentación]]

Feedback templates

2018-10-24T13:33:28Z

Howardsmiller: /* Save these questions as a new template */

{{Feedback}}
Within the Feedback Module you can create and re-use sets of Feedback questions using the Template tool.

The Templates tab provides the following template features:

==Use a template==

Previously saved Templates will be listed in this area and can be selected using the dropdown menu.

After selecting a Template, Moodle will display a preview of the Feedback questions contained within the Template and confirm Are you sure you want to use this template?

You will also be required to select one of two options:

;Delete old items
:Remove any questions/text types previously added to the Feedback Activity you are viewing before importing items from the selected Template

;Append new items
:Add items stored within the selected template to the current Feedback activity, to any existing questions/text types.

Once you have made your selection click Save changes to copy across the Feedback items or press Cancel to exit from the template copy process.

== Save these questions as a new template ==

After creating a new Feedback activity and populating it with questions, you can save it as a Template for re-use by yourself or others.

When saving a new Template enter a descriptive title in the Name field and choose whether you wish to make this Template available for use by others via the Public tickbox . A Public template may be viewed and re-used by users with appropriate access rights such as administrators and teacher/trainers. When a Public template is used as a basis for a new Feedback, the activity settings and questions within it may be edited by the teacher/trainer, however the original Template remains unchanged.

'''Note:''' To create public templates users must have the mod/feedback:createpublictemplate capability at the System/Site level. This will not be the case by default. You would either need to allow this capability in the 'Authenticated user' role or crate a specific side-wide role for permitted users.

== Delete Template... ==

To remove a Template you have created or have appropriate permissions to edit, from your Moodle site, use the Delete template... link and click the delete icon next to the corresponding template name.

==Export Questions==

The Export Questions tool allows you to save the questions/text types within your Feedback Activity in .xml format. Clicking the Export questions link will prompt you to Save or Open this file.

==Import Questions==

Where you have previously exported and saved questions from a Feedback activity in .xml format, you can reimport them into a new Feedback activity.

The Import questions tool is particularly useful where you need to import questions from a different instance of Moodle and the Template tool is not applicable.

Tip: You can also use the Import/Export ability to combine multiple Imports from multiple templates; also it can be used to avoid creating duplicates when using Append.

After clicking on the Import questions link you will be prompted to select one of the following options:

;Delete old items
:The current questions and all your user's responses will be deleted within the current Feedback activity

;Append new items
:All old questions and the assigned values will be preserved within the current Feedback activity and the imported questions will be added to the existing questions.

Use the Choose a file button to navigate to the course Files area and upload and/or select the relevant .xml file. Once selected use the Import from this file button to import the questions or use Cancel to return to the Templates general tab.

[[de:Feedback-Vorlagen]]
[[es:Plantillas de retroalimentación]]

Installation quick guide

2018-08-21T21:01:18Z

Howardsmiller: /* Getting Moodle */

{{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]]

Installation quick guide

2018-08-21T21:00:41Z

Howardsmiller: Wrong branch

{{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) 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]]

MySQL full unicode support

2018-07-17T08:43:49Z

Howardsmiller: /* File format */

{{Environment}}
==UTF-8==

UTF-8 is a character encoding that most websites use. It encodes each of the 1,112,064 valid code points. To store all of this information, four bytes is required. The most popular values are in the three byte region. MySQL by default only uses a three byte encoding and so values in the four byte range (eg. Asian characters and Emojis) can not be stored. Any attempt to enter a text that contains four byte characters will result in a Moodle database error.

MySQL does provide full four byte UTF-8 support, but it requires certain database settings to be configured. From version 3.3 on Moodle uses full UTF-8 for both MySQL and MariaDB by default. Existing databases will still run with partial support, but it is recommended to move over to full support.

Moodle comes with a Command Line Interface (CLI) script for converting to full UTF-8 for MySQL (and MariaDB). Before Moodle versions 3.1.5 and 3.2.2 this conversion tool would only change the Collation to some variant of 'utf8_bin'. 'utf8_unicode_ci' was the recommended Collation. We now recommend using 'utf8mb4_unicode_ci' which supports four byte characters (utf8_unicode_ci only supports three).

This script will attempt to change the database Collation, Character set, default table settings and column definitions.

To summarise:

* Fresh installs of Moodle 3.1.5 and 3.2.2 onwards will use utf8mb4 by default, if the database server is configured appropriately (see below).
* Sites upgrading to Moodle 3.1.5 or 3.2.2 can use the script to update to utf8mb4. In Moodle 3.3, 3.4 and 3.5 a warning will show that the database isn't using full UTF-8 support and suggest moving to 'utf8mb4_unicode_ci', but you may choose to keep using 'utf8_*'.

===File format===

To allow for large indexes on columns that are a varchar, a combination of settings needs to be set. The file format for the system needs to be using "Barracuda". This allows for the row format to be set to "Compressed" or "Dynamic". To enable this setting see the upgrade steps listed below. Moodle will not install if you have large format enabled without the Barracuda file format.

===File per table===

To enable this setting see the upgrade steps listed below.

===Large prefix===

This in conjunction with the row format being either "Compressed" or "Dynamic" allows for large varchar indexes above 191 characters.
To enable this setting see the upgrade steps listed below.

==Steps to upgrade==

Most important: Please backup your database before making any changes or running the CLI script.

* Change configuration settings for MySQL (exactly the same for MariaDB). This step is optional. You can run the script and it will try and make these changes itself. If errors occur then try manually changing these settings as listed below.
** On Linux based systems you will want to alter my.cnf. This may be located in '/etc/mysql/'.
** Make the following alterations to my.cnf:
<code>
[client]
default-character-set = utf8mb4

[mysqld]
innodb_file_format = Barracuda
innodb_file_per_table = 1
innodb_large_prefix

character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
skip-character-set-client-handshake

[mysql]
default-character-set = utf8mb4
</code>
* Restart your MySQL server.
* Run the CLI script to convert to the new Character set and Collation (requires Moodle 3.1.5, 3.2.2 or newer):
<pre>
$ php admin/cli/mysql_collation.php --collation=utf8mb4_unicode_ci
</pre>

NOTE: On very large sites this may take a long time to run. You should probably establish how long on a test install before taking your live site offline. In some cases you might consider dumping and re-importing your data.

* Adjust the $CFG->dboptions Array in your '''config.php''' to make sure that Moodle uses the right Collation when connecting to the MySQL Server:
<pre>
$CFG->dboptions = array(
…
'dbcollation' => 'utf8mb4_unicode_ci',
…
);
</pre>

If you only have access to the database command line (or something like phpmyadmin) you can try the following sql commands:
<code>
SET GLOBAL innodb_file_format = barracuda

SET GLOBAL innodb_file_per_table = 1

SET GLOBAL innodb_large_prefix = 'on'
</code>

* Try adding some Emojis (e.g. 😂💩) to your Moodle site to verify that the upgrade was successful.

[[Category:Environment|UTF-8]]
[[Category:UTF-8]]

[[es:MySQL soporte unicode completo]]
[[fr:Support unicode complet pour MySQL]]
[[de:MySQL Unicode Unterstützung]]

MySQL full unicode support

2018-07-17T08:40:31Z

Howardsmiller: /* UTF-8 */

{{Environment}}
==UTF-8==

UTF-8 is a character encoding that most websites use. It encodes each of the 1,112,064 valid code points. To store all of this information, four bytes is required. The most popular values are in the three byte region. MySQL by default only uses a three byte encoding and so values in the four byte range (eg. Asian characters and Emojis) can not be stored. Any attempt to enter a text that contains four byte characters will result in a Moodle database error.

MySQL does provide full four byte UTF-8 support, but it requires certain database settings to be configured. From version 3.3 on Moodle uses full UTF-8 for both MySQL and MariaDB by default. Existing databases will still run with partial support, but it is recommended to move over to full support.

Moodle comes with a Command Line Interface (CLI) script for converting to full UTF-8 for MySQL (and MariaDB). Before Moodle versions 3.1.5 and 3.2.2 this conversion tool would only change the Collation to some variant of 'utf8_bin'. 'utf8_unicode_ci' was the recommended Collation. We now recommend using 'utf8mb4_unicode_ci' which supports four byte characters (utf8_unicode_ci only supports three).

This script will attempt to change the database Collation, Character set, default table settings and column definitions.

To summarise:

* Fresh installs of Moodle 3.1.5 and 3.2.2 onwards will use utf8mb4 by default, if the database server is configured appropriately (see below).
* Sites upgrading to Moodle 3.1.5 or 3.2.2 can use the script to update to utf8mb4. In Moodle 3.3, 3.4 and 3.5 a warning will show that the database isn't using full UTF-8 support and suggest moving to 'utf8mb4_unicode_ci', but you may choose to keep using 'utf8_*'.

===File format===

To allow for large indexes on columns that are a varchar, a combination of settings needs to be set. The file format for the system needs to be using "Barracuda". This allows for the row format to be set to "Compressed" or "Dynamic". To enable this setting see the upgrade steps listed below.

===File per table===

To enable this setting see the upgrade steps listed below.

===Large prefix===

This in conjunction with the row format being either "Compressed" or "Dynamic" allows for large varchar indexes above 191 characters.
To enable this setting see the upgrade steps listed below.

==Steps to upgrade==

Most important: Please backup your database before making any changes or running the CLI script.

* Change configuration settings for MySQL (exactly the same for MariaDB). This step is optional. You can run the script and it will try and make these changes itself. If errors occur then try manually changing these settings as listed below.
** On Linux based systems you will want to alter my.cnf. This may be located in '/etc/mysql/'.
** Make the following alterations to my.cnf:
<code>
[client]
default-character-set = utf8mb4

[mysqld]
innodb_file_format = Barracuda
innodb_file_per_table = 1
innodb_large_prefix

character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
skip-character-set-client-handshake

[mysql]
default-character-set = utf8mb4
</code>
* Restart your MySQL server.
* Run the CLI script to convert to the new Character set and Collation (requires Moodle 3.1.5, 3.2.2 or newer):
<pre>
$ php admin/cli/mysql_collation.php --collation=utf8mb4_unicode_ci
</pre>

NOTE: On very large sites this may take a long time to run. You should probably establish how long on a test install before taking your live site offline. In some cases you might consider dumping and re-importing your data.

* Adjust the $CFG->dboptions Array in your '''config.php''' to make sure that Moodle uses the right Collation when connecting to the MySQL Server:
<pre>
$CFG->dboptions = array(
…
'dbcollation' => 'utf8mb4_unicode_ci',
…
);
</pre>

If you only have access to the database command line (or something like phpmyadmin) you can try the following sql commands:
<code>
SET GLOBAL innodb_file_format = barracuda

SET GLOBAL innodb_file_per_table = 1

SET GLOBAL innodb_large_prefix = 'on'
</code>

* Try adding some Emojis (e.g. 😂💩) to your Moodle site to verify that the upgrade was successful.

[[Category:Environment|UTF-8]]
[[Category:UTF-8]]

[[es:MySQL soporte unicode completo]]
[[fr:Support unicode complet pour MySQL]]
[[de:MySQL Unicode Unterstützung]]

Working with files

2018-07-11T13:06:28Z

Howardsmiller: /* Adding a new file type */

{{Managing content}}
==Adding files to your course==

Moodle provides an easy way for a teacher to present materials to their students. These materials may take the form of files such as word-processed documents or slideshow presentations. The materials can be displayed on the page either as individual items or bundled together inside folders. One teacher might for instance wish to share a single research document in pdf format; another might have a folder of sample past examination papers for students to download. Most types of files can be uploaded and accessed through Moodle but the student needs to have the correct software to be able to open them.

To add files to a Moodle course, you must first ensure you have the editing turned on.

===Drag and drop===
*If you are using a modern browser, you can simply click, hold and drag and drop a file directly onto your course page. You will know if drag and drop is available to you because you will (briefly) see a message at the top of your screen:
[[File:dragdropmessage.png]]

To drag and drop a folder, you must first compress/zip it using whichever program your computer has.

{{MediaPlayer | url = https://youtu.be/7WzrJDYK6jA | desc = Dragging and dropping files}}

===Add a resource or activity===
*Instead of drag and drop, you can click the link 'Add an activity or resource' and select either [[File]] or [[Folder]] from the activity chooser (or choose from the 'Add a resource' drop down menu, if this is present instead.)

{{MediaPlayer | url = https://youtu.be/sym4KWInX3c | desc = Uploading files}}

{|
| [[File:filefolder23.png|thumb|Selecting a file or folder in the activity chooser]]
| [[File:Workingwithfiles.png|thumb|The "Add a resource" drop down menu]]
|}

*The screen for uploading and displaying a file (or folder of files) includes an "add" button. Clicking on this button takes you to the [[File picker]] which is the name given to the file storage and access area within Moodle. Find out more about the places you can upload or add files from in the [[File picker]] page.
*There is also a block (with an arrow) into which you can drag and drop a file straight from your desktop into Moodle.

| [[File:newdraganddrop.png|thumb|Area for dragging and dropping files into]]
|}

==Unzipping uploaded files==
If you upload a zipped file, you need to unzip it for your students to see the individual files in Moodle. If you drag and drop the zip file you will be prompted to unzip the files and add them to a folder.
If you manually upload a zipped file to a folder you need to click on the file and click the Unzip button to extract the files from the zip. Once you click save, the students will be able to see the unzipped files in the folder.

==Viewing uploaded files==

* Once uploaded, files appear as thumbnails in the file manager for easy recognition.
* Files view can be easily toggled between icons view or a table view with sizes and dates, or a hierarchical list view.

{|
| [[File:truthumbnailsiconsview.png|thumb|File picker icon view]]
| [[File:tableview.png|thumb|File picker table view]]
| [[File:hierarchicallistview.png|thumb|File picker hierarchical list view]]
|}

==Editing or updating uploaded files==

*Clicking on the name of an uploaded file opens up a pop up dialogue box which allows file details quickly to be altered.

{|
| [[File:popupdialogue.png|thumb|File info popup dialogue]]
|}

==Creating an alias/shortcut==

*When an uploaded file - or a file from the Private files, Dropbox, File system or EQUELLA repositories - is re-used elsewhere on Moodle, the teacher has the option to make a copy (a new, unconnected version) or to create a shortcut or ''alias''.
*If an alias is created, then when the original file is updated, it will change in all instances of the alias. So a teacher might add course notes to their private files for example, and then add them into a number of courses. When the teacher makes an alteration in the file in their private files, this alteration will be reflected in all instances of the course notes.
*An alias can be recognised by its thumbnail. See the difference in the screenshot below between the original file (left) and the alias (right):
*To update a file, go to its original location (for example Private files) and upload your new version ''with the same name'' . You will be prompted to override or rename the file. Choose "override" and this file will replace your original file and the alisas/shortcuts will remain and all be updated to your latest version.
{|
| [[File:alias.png|thumb|Creating an alias]]
| [[File:shortcut1.png|frame]]
|}

===Areas in which aliases cannot be made===

An alias cannot be made in the following areas of Moodle:

* an assignment submission
* a forum post attachment
* a workshop submission
* a quiz essay
* a database activity file field

This is to prevent cases such as a student uploading an item for assessment and then subsequently changing the original in their private files. When a student uses a file from their private files in one of these instances, they do not see the options to "copy" or "create an alias". Below is an example of a file added to an assignment:

{|
| [[File:aliasassignment.png|thumb|Assignment submission with no option to create an alias]]
|}

==Site administration settings==

An administrator can add new file types and view, edit and delete existing file types from ''Site administration > Server > File types''. This means that, for example, if teachers and students on your site use a lot of files specific to a particular program, such files can now be recognised by Moodle, and, when downloaded, they will open in the correct program, rather than presenting themselves as a generic zip file.

[[File:Filetypes1.png|center|thumb|500px||Some examples from the list]]

===Adding a new file type===
1. Scroll down to the bottom of the page and click the "Add" button

2. Add the details of your file type, using the example below as a guide. This example will add the .mobi extension (for a Kindle ebook) with the standard document icon.

[[File:newfiletype.png|thumb|center|500px|Adding a new filetype]]

'''NOTE: The mimetype is set for a file when it is added/uploaded in Moodle (not when it is downloaded). If you change the mimetype associated with a file extension it will not make any difference to existing files. Only files uploaded in the future will have the new mimetype.'''

3. Click to save the changes and you will see your new file type has been added to the list:

[[File:customfileypesuccess.png|thumb|500px|center|New type in the list]]

===Restricting allowed file types===

* Allowed file types for [[Workshop]] submissions may be restricted
* It is possible to restrict file types for assignments. See [[Assignment settings]].

===Removing a file type===
*Clicking the X next to a file type will remove it from the site. You will be prompted to confirm before deletion.

===Editing an existing file type===
*Clicking the edit icon next to a file type will allow you to change certain details, for example the associated icon and description. If you don't wish to use the default description, you can specify your own custom description (with multi-language tags if your site supports multi-languages) or you can use an alternative language string from mimetypes.php.
===Google docs and docx===
Importing Google docs files as docx. See https://moodle.org/mod/forum/discuss.php?d=320144

==Alternative to MS PowerPoint and PDF files==
The [https://moodle.org/plugins/mod_revealjs Presentation] additional plugin displays multimedia HTML5 presentations and slide shows in users' web browsers. A web friendly and more feature rich alternative to MS PowerPoint and PDF. However, presentations must be uploaded to moodledata via FTP and you'll need to learn some basic HTML to create presentations for it.

==See also==
*HQ Youtube video tutorial: [http://youtu.be/Wt5Hgv-eouE Dragging and dropping files into Moodle].
*HQ Youtube video tutorial: [http://youtu.be/7i2roZ_OCyI Uploading files to Moodle].
*[https://www.youtube.com/watch?v=hvIlEkxJPrU How to zip files on Windows 10] (the first part of the video shows the process for Windows 7&8 as well).
*[https://www.youtube.com/watch?v=V0wkG6zOpjA How to zip files on Mac].
*[http://lewiscarr.co.uk/2014/11/moodle-file-sharing-explained/ File sharing explained] blog post by Lewis Carr.
*How to share a single file with students: [[File resource]].
*How to share a folder of files with students: [[Folder]].
*Questions about the file picker: [[File picker FAQ]].
* [[Restoring file aliases]].
*[http://www.youtube.com/watch?v=IrOKxYRJvGU How teachers upload files in Moodle 2 video].
*[https://moodle.org/mod/forum/discuss.php?d=332701#p1340373 Powerpoint alternative..for course presentation ] forum thread.

[[de:Arbeiten mit Dateien und Verzeichnissen]]
[[es:Trabajando con archivos]]
[[fr:Utilisation de fichiers]]

Roles FAQ

2018-03-08T11:06:45Z

Howardsmiller: /* How can I prevent a user from changing their own password? */

{{Roles}}
==What is the definition of a...==

;Capability
:A configurable aspect of program behavior. Moodle has 100s of capabilities. Each capability has a computer friendly name like [[Capabilities/mod/forum:rate|mod/forum:rate]] and a human-friendly name like "Rate posts."
;Permission
:Permissions are paired with each capability. There are four possible permission values: ''Allow'', ''Prevent'', ''Prohibit'' and ''Not set''/''Inherit''. (It is called not-set when defining roles and inherit when overriding permissions.)
;Role
:A named set of permissions that are associated with each capability. For example. the "Teacher" and "Student" roles come with the standard Moodle install.
;Context
:A functional area of Moodle. Contexts have a hierarchy. Examples of contexts include a course, activity module, or resource.

==Why isn't my role change taking effect?==

Certain capabilities e.g. [[Capabilities/moodle/user:changeownpassword|moodle/user:changeownpassword]] may only be applied in the system context, so giving such permissions by assigning a role in the course context will have no effect.

==Why do some users I know are in my course not appear in ''Participants''?==

Users assigned roles in a higher context, for example users assigned the role of teacher in the course category are technically not enrolled in the course and so will not appear in the Participants link in the [[Navigation block]] but can be found via ''Course administration > Users > Other users''.

==How can I prevent a user from changing their own password?==

==== Using roles ====

To prevent a user from changing their own password, you must make sure they do not have [[Capabilities/moodle/user:changeownpassword|moodle/user:changeownpassword]] = Allow in the System context. The Authenticated user role (which is assigned to users in the System context) has moodle/user:changeownpassword = Allow by default, so you have two choices:
# Edit Authenticated user, setting moodle/user:changeownpassword = Not set
# Create a new role CannotChangeOwnPassword with moodle/user:changeownpassword = Prevent and all other permissions Not set. Choose "system" for the context type and assign the role to selected users in the System context via ''Administration>Site administration -> Users -> Permissions -> Assign system roles).''

Choice (1) will prevent ''all'' users from changing their passwords (except for the administrator, who can do anything). To selectively allow selected users (say teachers) to change their passwords, you could create a new role CanChangeOwnPassword with moodle/user:changeownpassword = Allow and all other permissions not set and assign the role to selected users in the System context (Site administration -> Users -> Permissions -> Assign system roles).

Choice (2) allows you to be selective, but if you have a lot of users that you want to prevent (say, all students), you will have to make a lot of role assignments in the System context. There is currently no convenient way to do this, so you might consider choice (1).

Note that you MUST deal with this permission in the System context.

==== Alternative solution ====

Go to Site administration > Plugins > Manage authentication plugins. Find the 'forgottenpasswordurl' setting and point it to a static HTML page on your server (or even a Moodle Page resource on the front page). Explain your password policy on that page. This stops users changing passwords. This applies to ALL users, however, so admins will need to fix any lost passwords for the whole site.

==How can I prevent a user from editing their own profile?==

See [[Roles_FAQ#How can I prevent a user from changing their own password? | How can I prevent a user from changing their own password?]] The answer to this question is the same if you substitute ''edit their own profile'' for ''change their own password'' and ''[[Capabilities/moodle/user:editownprofile|moodle/user:editownprofile]]'' for ''moodle/user:changeownpassword.''

== How can I allow a "test" Student user to see courses that are hidden?==

Having a test user to try out courses before you open them to regular students is useful. But if the course is hidden, then the enroled test student will not be able to see it. The solution to this problem, if you do not wish to make the hidden course visible yet, is to create a ''Student tester rol'', a clone of the default Student role and then set the ability to see hidden courses to Allow.

* Create a new role in ''Site administration > Users > Permissions > Define roles > Add a new role'', then for ''Use role or archtype'' choose ''ARCHETYPE: Student'' (or Student if you have customized the default Student role already)
* Give the role a new shortname and fullname as appropriate, e.g. studenttester, Student Tester
* Change the 'View hidden courses' [[Capabilities/moodle/course:viewhiddencourses|course:viewhiddencourses]] capability from Not Set to Allow
* Click the 'Create this role button'

Now enrol your test student in the course using this new role instead of the Student role, and they will be able to see and work in the course as a normal student even when the course is hidden. They will not be able to see other hidden courses in which they are not enroled.

==How do I change the name for "teacher" in the course description?==

Either
* Edit the role of Teacher via ''Site administration > Users > Permissions > Define roles'' and rename it. The new name will apply site-wide.
Or
* Create a duplicate teacher role with an alternative name and assign users the duplicate teacher role as appropriate in the course context. In ''Site administration > Appearance > Course contact'' select the alternative name for teacher that you wish to be displayed in the course description when courses are listed. For example, copy the standard teacher role and call it Instructor and only show that role as the course contact.
Or
* Create a new "dummy" role (no capabilities) with those names and assign them to teachers along with the real roles. select the alternative name for teacher that you wish to be displayed in the course description when courses are listed. For example, copy the guest role, call it Lead Teacher and make this the course contact. You may have 5 teachers in the course but only one name will appear as Lead Teacher. If nobody is assigned the role Lead Teacher, no course contact will show.
Or
*Names for different roles in a course may be changed in the [[Course settings|Course administration > edit settings]] "Role renaming" fields. For example, some courses the teacher wants the title "Professor", or "Chief" or "Mentor".
Or
*[[Language customization|Edit the language files]] and change any word you want.

==How do I enable teachers to set role overrides?==

#Access ''Site administration > Users > Permissions > Define roles''.
#Edit the teacher role and change the capability [[Capabilities/moodle/role:safeoverride|moodle/role:safeoverride]] to allow.
#Click the button "Save changes".
#Click the tab "Allow role overrides" (in ''Site administration > Users > Permissions > Define roles'').
#Check the appropriate box(s) in the teacher row to set which role(s) teachers can override. Most likely it will just be the student role (you don't want teachers to be able to override admins!), so check the box where the teacher row intersects with the student column.
#Click the button "Save changes".

==How do I enable teachers to assign other teachers in a course?==

This is disabled by default but it can be switched on by modifying the teacher's role. In ''Site administration > Users > Permissions > Define roles'' select the "Allow role assignments" tab and tick the checkbox where Teacher and Teacher intersect.

==Why doesn't "Switch role to.." within a course seem to work properly?==

This feature is intended for teachers so that they can see how their course appears for students. It isn't a reliable view however, as some features do not display correctly when viewed by a teacher who has switched their role to a student. Certain actions (specifically submitting assignments) are excluded from working with 'switch roles' (as the submitted work would not be visible on the grading pages, due to the user not having the 'submit' permission when they have not switched roles).For that reason it is always preferable where possible to have a "test" student log in to use.

==How can I allow a non-editing teacher to "switch role to " a student?==

# In ''Site administration > Users > Permissions > Define roles'', edit the non-editing teacher role and set the capability "moodle/role:switchroles" to "allow". This will then allow them to switch their role to a student or a guest (as defined on the ''Allow role switches'' screen.)

==I accidentally deleted a default role. How do I get it back?==

# Go to ''Site administration > Users > Permissions > Define roles'' and click the 'Add a new role' button
# Select the role e.g. Teacher to use
# Click continue
# Fill in the short name and custom full name
# Click the 'Create this role' button

==Are there any example roles?==

Yes. See [[Creating_custom_roles#Example_custom_roles| the current list]].

==How do I enable logged-in users to participate in front page activities?==

Either:

# Go to ''Administration > Site administration > Users > Permissions > Define roles'' and edit the 'Authenticated user on frontpage' role
# Allow capabilities for the front page activities
# Click the 'Save changes' button

Or:

# Go to ''Administration > Site administration > Front Page > Front Page settings''
# Set the default front page role to student
# Click the 'Save changes' button

==How can I prevent students from editing their profile?==

If you only want students to be prevented from editing their profile, and not all users, you can create a new role, such as Restricted user as described in the [[Demo teacher role]], with moodle/user:editownprofile set to prevent, and assign it to all students in the system context.

Alternatively, you could change moodle/user:editownprofile to not set for the [[Authenticated user role]], then create a new role for teachers with moodle/user:editownprofile set to allow.

==Why can't I add teachers or students site wide in Moodle?==

You can, however teachers and students typically work in one or more individual courses. It is unusual for a student to be studying every single course on your Moodle and unusual for a teacher to be teaching every single course. Therefore, the default Moodle does not use these as system wide roles. The Manager role might be one that makes sense to assign on a system or category context.

To assign a teacher or student site-wide

# Go to ''Site administration > Users > Permissions > Define roles'' and edit the role to include the ''system'' context.
#Then search for and allow the capability [[Capabilities/moodle/course:view|moodle/course:view]]
#Then assign users to this role via ''Administration>Site administration>Users>Permissions>Assign system roles''

It might be preferable to create a new role based on the teacher or student and assign this in the System context. Then assign individuals to that role.

==Why isn't my custom role listed as an available role for assigning?==

When adding/editing a custom role, be sure to tick one or more context types where the role may be assigned.

[[File:context types where role may be assigned.png]]

==How can I set a role back to default?==

# Go to ''Site administration > Users > Permissions > Define roles'' and click on the name of the role
# Click the Reset button
# Select items for reset as desired
# Click the continue button.

==Permissions don't seem to be working correctly. What can I do?==

[[File:reviewing badge permissions.png|thumb|Reviewing role permissions]]It is recommended that permissions for each role are reviewed and set according to the role archetype.

# Go to ''Administration > Site administration > Users > Permissions > Define roles'' and click the edit icon opposite a role
# Click the 'Show advanced' button to reveal the different permission settings
# Review permissions (filtering for particular permissions as appropriate) and, unless there is a good reason to do otherwise, change permissions so that all are set to the highlighted value
# Click the 'Save changes' button
# Repeat steps 1 to 4 for each role

==Is there a role that can be safely used for a government inspector/supervisor ?==
The [https://github.com/3-bits/moodle-role_sepe SEPE] role is used for a (Spanish) government supervisor who can access all Moodle courses without being able to change anything. It can be used in any other country/ language.

==Any further questions?==

Please visit the [http://moodle.org/mod/forum/view.php?id=6826 Roles and Capabilities forum] on moodle.org.

[[Category:FAQ]]

[[de:Rollen FAQ]]
[[es:FAQ_roles]]
[[fr:FAQ des rôles]]
[[ja:ロールFAQ]]

MySQL full unicode support

2017-12-11T16:03:55Z

Howardsmiller: /* Steps to upgrade */

{{Environment}}
==UTF-8==

UTF-8 is a character encoding that most websites use. It encodes each of the 1,112,064 valid code points. To store all of this information, four bytes is required. The most popular values are in the three byte region. MySQL by default only uses a three byte encoding and so values in the four byte range (eg. Asian characters and Emojis) can not be stored. Any attempt to enter a text that contains four byte characters will result in a Moodle database error.

MySQL does provide full four byte UTF-8 support, but it requires certain database settings to be configured. From version 3.3 on Moodle uses full UTF-8 for both MySQL and MariaDB by default. Existing databases will still run with partial support, but it is recommended to move over to full support.

Moodle comes with a Command Line Interface (CLI) script for converting to full UTF-8 for MySQL (and MariaDB). Before Moodle versions 3.1.5 and 3.2.2 this conversion tool would only change the Collation to some variant of 'utf8_bin'. 'utf8_unicode_ci' was the recommended Collation. We now recommend using 'utf8mb4_unicode_ci' which supports four byte characters (utf8_unicode_ci only supports three).

This script will attempt to change the database Collation, Character set, default table settings and column definitions.

To summarise:

* Fresh installs of Moodle 3.1.5 and 3.2.2 onwards will use utf8mb4 by default, if the database server is configured appropriately (see below).
* Sites upgrading to Moodle 3.1.5 or 3.2.2 can use the script to update to utf8mb4. In Moodle 3.3 a warning will show that the database isn't using full UTF-8 support and suggest moving to 'utf8mb4_unicode_ci', but you may choose to keep using 'utf8_*'.

===File format===

To allow for large indexes on columns that are a varchar, a combination of settings needs to be set. The file format for the system needs to be using "Barracuda". This allows for the row format to be set to "Compressed" or "Dynamic". To enable this setting see the upgrade steps listed below.

===File per table===

To enable this setting see the upgrade steps listed below.

===Large prefix===

This in conjunction with the row format being either "Compressed" or "Dynamic" allows for large varchar indexes above 191 characters.
To enable this setting see the upgrade steps listed below.

==Steps to upgrade==

Most important: Please backup your database before making any changes or running the CLI script.

* Change configuration settings for MySQL (exactly the same for MariaDB). This step is optional. You can run the script and it will try and make these changes itself. If errors occur then try manually changing these settings as listed below.
** On Linux based systems you will want to alter my.cnf. This may be located in '/etc/mysql/'.
** Make the following alterations to my.cnf:
<code>
[client]
default-character-set = utf8mb4

[mysqld]
innodb_file_format = Barracuda
innodb_file_per_table = 1
innodb_large_prefix

character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
skip-character-set-client-handshake

[mysql]
default-character-set = utf8mb4
</code>
* Restart your MySQL server.
* Run the CLI script to convert to the new Character set and Collation (requires Moodle 3.1.5, 3.2.2 or newer):
<pre>
$ php admin/cli/mysql_collation.php --collation=utf8mb4_unicode_ci
</pre>

NOTE: On very large sites this may take a long time to run. You should probably establish how long on a test install before taking your live site offline. In some cases you might consider dumping and re-importing your data.

* Adjust the $CFG->dboptions Array in your '''config.php''' to make sure that Moodle uses the right Collation when connecting to the MySQL Server:
<pre>
$CFG->dboptions = array(
…
'dbcollation' => 'utf8mb4_unicode_ci',
…
);
</pre>

If you only have access to the database command line (or something like phpmyadmin) you can try the following sql commands:
<code>
SET GLOBAL innodb_file_format = barracuda

SET GLOBAL innodb_file_per_table = 1

SET GLOBAL innodb_large_prefix = 'on'
</code>

* Try adding some Emojis (e.g. 😂💩) to your Moodle site to verify that the upgrade was successful.

[[Category:Environment|UTF-8]]
[[Category:UTF-8]]

[[es:MySQL soporte unicode completo]]
[[fr:Support unicode complet pour MySQL]]
[[de:MySQL Unicode Unterstützung]]

MySQL full unicode support

2017-12-11T16:00:31Z

Howardsmiller: /* Steps to upgrade */

{{Environment}}
==UTF-8==

UTF-8 is a character encoding that most websites use. It encodes each of the 1,112,064 valid code points. To store all of this information, four bytes is required. The most popular values are in the three byte region. MySQL by default only uses a three byte encoding and so values in the four byte range (eg. Asian characters and Emojis) can not be stored. Any attempt to enter a text that contains four byte characters will result in a Moodle database error.

MySQL does provide full four byte UTF-8 support, but it requires certain database settings to be configured. From version 3.3 on Moodle uses full UTF-8 for both MySQL and MariaDB by default. Existing databases will still run with partial support, but it is recommended to move over to full support.

Moodle comes with a Command Line Interface (CLI) script for converting to full UTF-8 for MySQL (and MariaDB). Before Moodle versions 3.1.5 and 3.2.2 this conversion tool would only change the Collation to some variant of 'utf8_bin'. 'utf8_unicode_ci' was the recommended Collation. We now recommend using 'utf8mb4_unicode_ci' which supports four byte characters (utf8_unicode_ci only supports three).

This script will attempt to change the database Collation, Character set, default table settings and column definitions.

To summarise:

* Fresh installs of Moodle 3.1.5 and 3.2.2 onwards will use utf8mb4 by default, if the database server is configured appropriately (see below).
* Sites upgrading to Moodle 3.1.5 or 3.2.2 can use the script to update to utf8mb4. In Moodle 3.3 a warning will show that the database isn't using full UTF-8 support and suggest moving to 'utf8mb4_unicode_ci', but you may choose to keep using 'utf8_*'.

===File format===

To allow for large indexes on columns that are a varchar, a combination of settings needs to be set. The file format for the system needs to be using "Barracuda". This allows for the row format to be set to "Compressed" or "Dynamic". To enable this setting see the upgrade steps listed below.

===File per table===

To enable this setting see the upgrade steps listed below.

===Large prefix===

This in conjunction with the row format being either "Compressed" or "Dynamic" allows for large varchar indexes above 191 characters.
To enable this setting see the upgrade steps listed below.

==Steps to upgrade==

Most important: Please backup your database before making any changes or running the CLI script.

* Change configuration settings for MySQL (exactly the same for MariaDB). This step is optional. You can run the script and it will try and make these changes itself. If errors occur then try manually changing these settings as listed below.
** On Linux based systems you will want to alter my.cnf. This may be located in '/etc/mysql/'.
** Make the following alterations to my.cnf:
<code>
[client]
default-character-set = utf8mb4

[mysqld]
innodb_file_format = Barracuda
innodb_file_per_table = 1
innodb_large_prefix

character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
skip-character-set-client-handshake

[mysql]
default-character-set = utf8mb4
</code>
* Restart your MySQL server.
* Run the CLI script to convert to the new Character set and Collation (requires Moodle 3.1.5, 3.2.2 or newer):
<pre>
$ php admin/cli/mysql_collation.php --collation=utf8mb4_unicode_ci
</pre>

NOTE: On very large sites this may take a long time to run. You should probably establish how long on a test install before taking your live site offline. In some cases it may consider dumping and re-importing your data.

* Adjust the $CFG->dboptions Array in your '''config.php''' to make sure that Moodle uses the right Collation when connecting to the MySQL Server:
<pre>
$CFG->dboptions = array(
…
'dbcollation' => 'utf8mb4_unicode_ci',
…
);
</pre>

If you only have access to the database command line (or something like phpmyadmin) you can try the following sql commands:
<code>
SET GLOBAL innodb_file_format = barracuda

SET GLOBAL innodb_file_per_table = 1

SET GLOBAL innodb_large_prefix = 'on'
</code>

* Try adding some Emojis (e.g. 😂💩) to your Moodle site to verify that the upgrade was successful.

[[Category:Environment|UTF-8]]
[[Category:UTF-8]]

[[es:MySQL soporte unicode completo]]
[[fr:Support unicode complet pour MySQL]]
[[de:MySQL Unicode Unterstützung]]

OAuth 2 Google service

2017-10-23T10:07:32Z

Howardsmiller: /* OAuth 2 Google service setup */

{{OAuth2}}
==Features requiring the OAuth 2 Google service==

You will need to set up an OAuth 2 Google service in order to use the following features:

* [[Google Drive repository]]
* [[OAuth 2 authentication]] for enabling users to log in to Moodle with their Google account
* [[Google Drive converter]] for converting assignment submission files to PDF for teachers to annotate

==OAuth 2 Google service setup==

To set up an OAuth 2 client with Google, first we need to login to the [https://console.developers.google.com/ Google Developers Console] and create a new project.

Create a new project using the menu at the top of the page.

[[File:google-1-create-new.png|none|frame|Create new project]]

Call the new project whatever you like, this name is not shown to users when they are asked to authorise this application.

[[File:google-2-create-new-modal.png|none|frame|Name the project]]

Select "credentials" from the menu on the left.

[[File:google-3-credentials.png|none|frame|Switch to credentials page]]

Setup the consent screen for your application. This is where you provide the public information that is shown to users when they are asked to authorise your application. Setting a product name is the minimum information that is required, but the more information you provide here - the more confidence users will have when granting this authorisation.

[[File:google-4-consent.png|none|frame|Setup consent screen]]

Now you can create some client credentials. Switch to the credentials tab and create a new OAuth client ID.

[[File:google-5-oauth-credentials.png|none|frame|Create an OAuth Client ID]]

Setup the credentials for a Web Application. The most important setting here is to set the callback URL ("Authorized redirect URI"). This must be set to "your moodle site url + /admin/oauth2callback.php". If your moodle site was accessible at <nowiki>https://lemon.edu/</nowiki> then this callback URL should be set to <nowiki>https://lemon.edu/admin/oauth2callback.php</nowiki>. Make sure this box has saved properly.

[[File:google-6-web-application-credentials.png|none|frame|Set the callback URL]]

When you have saved the information on this page, Google will give you the client ID and client secret that you need to enter into Moodle.

[[File:google-7-oauth-details.png|none|frame|Got my secrets!]]

Finally we have to enable the Drive API (if we want to use the google drive repository or file converter plugins).

[[File:google-8-library.png|none|frame|View the Library tab]]

[[File:google-9-select-drive.png|none|frame|Select Drive API]]

[[File:google-10-enable-drive.png|none|frame|Enable the API]]

==App verification==

NOTE: If you are just using this for document conversion you will not need to verify (as it only uses one account). You will, however, need to verify your ownership of your domain (see, [https://support.google.com/webmasters/answer/35179])

The Google Drive repository and Google Drive converter also require the app to be verified by completing the [https://support.google.com/code/contact/oauth_app_verification OAuth Developer Verification Form]. The list of scopes that Moodle requires are: <code><nowiki>openid profile email https://www.googleapis.com/auth/drive</nowiki></code>.

See the discussion [https://moodle.org/mod/forum/discuss.php?d=356871 Google Drive Repository and Moodle 3.3.1] for more details.

[[es:Servicio OAuth 2 Google]]
[[de:OAuth2 Google Service]]

OAuth 2 Google service

2017-10-23T10:06:27Z

Howardsmiller: /* App verification */

{{OAuth2}}
==Features requiring the OAuth 2 Google service==

You will need to set up an OAuth 2 Google service in order to use the following features:

* [[Google Drive repository]]
* [[OAuth 2 authentication]] for enabling users to log in to Moodle with their Google account
* [[Google Drive converter]] for converting assignment submission files to PDF for teachers to annotate

==OAuth 2 Google service setup==

To set up an OAuth 2 client with Google, first we need to login to the [https://console.developers.google.com/ Google Developers Console] and create a new project.

Create a new project using the menu at the top of the page.

[[File:google-1-create-new.png|none|frame|Create new project]]

Call the new project whatever you like, this name is not shown to users when they are asked to authorise this application.

[[File:google-2-create-new-modal.png|none|frame|Name the project]]

Select "credentials" from the menu on the left.

[[File:google-3-credentials.png|none|frame|Switch to credentials page]]

Setup the consent screen for your application. This is where you provide the public information that is shown to users when they are asked to authorise your application. Setting a product name is the minimum information that is required, but the more information you provide here - the more confidence users will have when granting this authorisation.

[[File:google-4-consent.png|none|frame|Setup consent screen]]

Now you can create some client credentials. Switch to the credentials tab and create a new OAuth client ID.

[[File:google-5-oauth-credentials.png|none|frame|Create an OAuth Client ID]]

Setup the credentials for a Web Application. The most important setting here is to set the callback URL. This must be set to "your moodle site url + /admin/oauth2callback.php". If your moodle site was accessible at <nowiki>https://lemon.edu/</nowiki> then this callback URL should be set to <nowiki>https://lemon.edu/admin/oauth2callback.php</nowiki>.

[[File:google-6-web-application-credentials.png|none|frame|Set the callback URL]]

When you have saved the information on this page, Google will give you the client ID and client secret that you need to enter into Moodle.

[[File:google-7-oauth-details.png|none|frame|Got my secrets!]]

Finally we have to enable the Drive API (if we want to use the google drive repository or file converter plugins).

[[File:google-8-library.png|none|frame|View the Library tab]]

[[File:google-9-select-drive.png|none|frame|Select Drive API]]

[[File:google-10-enable-drive.png|none|frame|Enable the API]]

==App verification==

NOTE: If you are just using this for document conversion you will not need to verify (as it only uses one account). You will, however, need to verify your ownership of your domain (see, [https://support.google.com/webmasters/answer/35179])

The Google Drive repository and Google Drive converter also require the app to be verified by completing the [https://support.google.com/code/contact/oauth_app_verification OAuth Developer Verification Form]. The list of scopes that Moodle requires are: <code><nowiki>openid profile email https://www.googleapis.com/auth/drive</nowiki></code>.

See the discussion [https://moodle.org/mod/forum/discuss.php?d=356871 Google Drive Repository and Moodle 3.3.1] for more details.

[[es:Servicio OAuth 2 Google]]
[[de:OAuth2 Google Service]]

Theme settings

2017-10-11T10:51:47Z

Howardsmiller: /* Custom menu items */

{{Themes}}
== Theme settings ==
An administrator can change theme settings in ''Administration > Site administration > Appearance > Themes > Theme settings''.

[[File:Themesettings.png]]

===Theme list===
This lists the themes available for course and user themes. Leave this blank to allow any valid theme to be used. If you want to shorten the theme menu, you may specify a comma-separated list of names, though don't use spaces (e.g. standard,orangewhite).

You can preview the available themes in ''Administration > Site Administration > Appearance > Themes > Themes selector.''

===Theme designer mode===
Turn this on if you are designing and testing themes as it will stop the themes being cached and enable you to see theme changes quickly. (You can also do this with the Clear theme cache button on the theme selector page.)

===Allow user themes===
If the option ''allowuserthemes'' is enabled, each user may select their preferred theme on the edit profile page. All Moodle pages will be displayed in the user's theme, apart from courses where a course theme has been set.

'''NOTE:''' the user's theme will not be available in mobile and tablet devices unless the option ''enabledevicedetection'' is unchecked.

===Allow course themes===
If you enable this, then teachers will be able to set their own course themes. Course themes override all other theme choices (site, user, or session themes).

*If the option ''allowcoursethemes'' is enabled, each editing teacher may select their course theme via the Force theme option on the [[course/edit|Course settings]] page. The course will always be displayed in the theme specified in the course setting, with user and the site themes being overwritten.

'''NOTE:''' the course theme will not be available in mobile and tablet devices unless the option ''enabledevicedetection'' is unchecked.

===Allow category themes===
When enabled, themes can be set at the category level. This will affect all child categories and courses unless they have specifically set their own theme. WARNING: Enabling category themes may affect performance, as it will result in a few extra DB queries on each page, so only turn this on if you need it!

'''NOTE:''' the category theme will not be available in mobile and tablet devices unless the option ''enabledevicedetection'' is unchecked.

===Allow theme changes in the URL===

*If this is checked then the theme may be changed by adding <code>?theme=theme_name</code> (or <code>&theme=theme_name</code> if there are other URL parameters) to the URL in the browser.

Theme names used as the URL parameter should be the shortname of the theme, which you can see in ''Site administration > Plugins > Plugins overview'' and scroll down to the Themes section near the bottom. Remove the "theme_" prefix to find the proper shortname. Theme shortnames are usually the same as the main theme name, eg. Clean is 'clean', so your URL parameter for it will be: <code>?theme=clean</code>. Shortnames are always lower case. Themes with multiple words are usually the same but spaces are replaced by underscores, for example the theme "Formal white" should be entered as <code>?theme=formal_white</code>.

[[File:themeshortnames.jpg]]

''Tip:'' You can turn this on to aid in troubleshooting problems that may be theme related. This will allow you to switch to a standard or different theme for your own session without affecting other users or the site theme.

===Allow users to hide blocks===
Allows users to display and hide blocks

===Allow blocks to use the docks===
*If the theme allows it, then checking this will allow the user to move blocks to the side dock.

===Custom menu items===
{{Note|The [[Boost theme]] does not support submenus in the custom menu setting.}}

The custommenuitems setting allows you to create a drop down menu that can be displayed by themes that support it.

You are able to create the custom menu by entering custom menu items one per line into the setting. Each item is preceded by a number of hyphens (-), the number of hyphens determines the depth of the item. So items that are '''NOT''' preceded by a hyphen appear on the top level of the menu (always visible), items with a single hyphen appear on a drop down menu below the previous top level item, and items with two hyphens appear on a drop down menu below the previous first level item and so on - ''if the theme allows submenus.''

The content of each item is constructed of up to three bits, each separated by a '''|''' (Shift + \) character. The bits are '''label''' | '''url''' | '''tooltip'''.
; label : This is the text that will be shown within the menu item. You must specify a label for every item on the menu.
; url : This is the URL that the user will be taken to it they click the menu item. This is optional, if not provided then the item will not link anywhere.
; tooltip : If you provide a URL you can also choose to provide a tooltip for the link that is created with the URL. This is optional and if not set the label is used as the tooltip for the menu item.

The following is an example of how you would create a custom menu:

<pre>
Moodle community|http://moodle.org
-Moodle free support|http://moodle.org/support
-Moodle development|http://moodle.org/development
--Moodle Tracker|http://tracker.moodle.org
--Moodle Docs|https://docs.moodle.org
-Moodle News|http://moodle.org/news
Moodle company
-Moodle commercial hosting|http://moodle.com/hosting
-Moodle commercial support|http://moodle.com/support
</pre>

Note: The custom menu does not escape characters within the label. If you want to use a special HTML character such as an ampersand you must escape it yourself within the label. e.g. use &amp; instead of &.

==== Multilanguage support ====

You can add a language code (or a comma separated list of codes) as the 4th item of the line. The line will be then printed if and only if the user has currently selected the listed language. For example:

<pre><nowiki>
English only|http://moodle.com|English only item|en
German only|http://moodle.de|Deutsch|de,de_du,de_kids
</nowiki></pre>

==== Adding other attributes to the HTML ====
Other attributes, such as '''target''' can be added:
<pre><nowiki>
Moodle Homepage|http://moodle.org" target="_blank
</nowiki></pre>
The first quote closes the href attribute, allowing other attributes to be added. Do not add the closing quotation mark on the final attribute, it is added automatically by Moodle.

===User menu items===

The customusermenuitems setting allows you to add or remove items from the user menu.

Three items, Dashboard, Profile and Log out are automatically created and can not be changed.

Other user menu items can be set in this area by removing them, reordering them, or adding custom ones. There are three default items:

<pre>
grades,grades|/grade/report/mygrades.php|grades
messages,message|/message/index.php|message
preferences,moodle|/user/preferences.php|preferences
</pre>

The format for each is the | "pipe" character delineating three parts:

# a string in "langstringname, componentname" form or as plain text
# a path to a file to run
# an icon either as a pix icon or as a path to a file URL

Notes:

1) You can refer to a language string in the users language pack by its string name. For example, in the third line above for the default settings, "preferences" is the name of the language string, and "moodle" is the language file it is located in. See Language customisation for more information. If you put a text here instead of a reference to a language string, that text will always show up and not be language specific.

2) The examples are to php files inside the Moodle site, so "/message/index.php" is the path on the current Moodle instance. You could also put a path or URL here to files outside of Moodle as well.

3) The example defaults of icons point to files in the /pix/t/ directory on the Moodle server. You can use any of the pre-existing icon names there (without a file extension). You can add your images to that directory to expand the icon list, or you can prefix the icon name with ../ if you want to use icons from other pix folders. Alternatively, you can use a URL to point to a file elsewhere. "Icon" files are in both png and svg format.

Tip: If you do not specify an icon, the Moodle will supply the gear icon that is used by "Preferences" next to the entry.

Custom item example:

<pre>Help Center|/course/view.php?id=2|check</pre>

This will add item called "Help Center" which links to a course on the same site with id=2 which has been set up as a help center for all users, and it will show using the standard check mark icon.

[[File:m32-defaultusermenuitems.jpg|center]]

===Enable device detection===

If a tablet or mobile theme is set, AND the user is using a tablet or mobile, theme associated with the device is used, always overriding the course, category or user theme.

If no tablet or mobile theme is set, course, category or user themes will be used.

===Device detection regular expressions===
This will allow you to customize the theme selector options. For example, you can add a custom theme for IE6 and another for Windows CE by entering the identifying expressions the browser sends and the "Return value" you want to display as the theme selectors "Device type".

==Special themes==

=== Session themes ===
Moodle offers an additional way to set a theme - the '''session theme'''. This is set with the URL and lasts until you log out. When you next login, the site/course/user themes are active again. This option is great for theme testing and works perfectly when you want to enable different themes for different situations.

For example you can offer a special link for PDA users and integrate the session theme ''orangewhitepda'' in that link. Nobody needs to change any settings, you just click on that link. The session theme is called by the URL parameter <code>&theme=orangewhitepda</code>. The whole URL without the session theme could look like <code><nowiki>http://mymoodlesite.org/course/view.php?id=18</nowiki></code> and with the parameter for the PDA theme like <code><nowiki>"http://mymoodlesite.org/course/view.php?id=18&theme=orangewhitepda"</nowiki></code>.

In a standard Moodle installation, session themes are not active. To activate them the administrator must add the parameter <code>$CFG->allowthemechangeonurl = true;</code> to the Moodle ''config.php'' file in the Moodle base directory.

=== Page theme ===
A page theme is for special page-only themes set by code, use <code>$PAGE->force_theme()</code>.

== Theme hierarchy ==
Here is the usual order that themes are considered by the Moodle interface.

{| style="border:1px dashed #ddd"
|- style="vertical-align:top;text-align:left"
!Theme type
! style="background:#eee"|Overwrites
!Display
! style="background:#eee"|Setting type
|- style="vertical-align:top"
|Site
|style="background:#eee"| -
|all pages*
|style="background:#eee"|saved in theme profile
|- style="vertical-align:top"
|User
|style="background:#eee"|Site theme
|all pages*
|style="background:#eee"|saved in user profile
|- style="vertical-align:top"
|Course
|style="background:#eee"|Site, user and session themes
|one course
|style="background:#eee"|saved in course profile
|- style="vertical-align:top"
|Session
|style="background:#eee"|Site and user themes
|all pages*
|style="background:#eee"|temporary until logout
|}
(* except courses with the course theme set)

=== Change default hierarchy===
The priority of themes can be set via the /moodle/config.php file. The order defines which theme wins when there are several set at different levels. You can set a variable called $CFG->themeorder (see config-dist.php for more details). By default it is set to:

<code><nowiki>$CFG->themeorder = array('course', 'category', 'session', 'user', 'site');</nowiki></code>

==Particular theme settings==

Logo, tagline, link colour, column width, custom CSS and other settings for a particular theme may be set by an administrator in ''Administration > Site administration > Appearance > Themes > Theme name''.

==See also==
*[http://youtu.be/QfhANg1MAZ0 Moodle Theme Settings Page] MoodleBites video on YouTube

[[es:Configuración de temas]]
[[fr:Réglages des thèmes]]
[[ja:テーマ設定]]
[[de:Design-Einstellungen]]

Course categories

2017-08-18T09:25:21Z

Howardsmiller: /* Adding a category */

{{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]]

Installation quick guide

2017-08-11T09:50:56Z

Howardsmiller: /* Create data directory */

{{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_{{Version2}}_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]]

[[ja:インストールクイックスタート]]
[[de:Installation in Kürze]]
[[fr:Installation_rapide]]
[[es:Inicio_Rápido_de_Instalación]]

Installation quick guide

2017-08-11T09:49:08Z

Howardsmiller: /* Install Moodle code */

{{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_{{Version2}}_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. Typically, either make it owned by the web server user or give it write permissions for 'everyone'.

==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]]

[[ja:インストールクイックスタート]]
[[de:Installation in Kürze]]
[[fr:Installation_rapide]]
[[es:Inicio_Rápido_de_Instalación]]

Installation quick guide

2017-08-11T09:48:29Z

Howardsmiller: Pointless message in "advanced" section

{{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_{{Version2}}_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. Typically, either make it owned by the web server user or give it write permissions for 'everyone'.

==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/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]]

[[ja:インストールクイックスタート]]
[[de:Installation in Kürze]]
[[fr:Installation_rapide]]
[[es:Inicio_Rápido_de_Instalación]]

Installing Moodle

2017-08-11T09:40:24Z

Howardsmiller: /* If something goes wrong... */

{{Template:Installing Moodle}}
''This page explains how to install Moodle. If you are an expert and/or in a hurry try [[Installation Quickstart]].''

If you just want to try Moodle on a standalone machine there are 'one-click' installers for Windows (see [[Complete install packages for Windows]]) and for OSX (see [[Complete Install Packages for Mac OS X]]) or [[ install on OS X]]. These are unsuitable for production servers.

== Requirements ==

Moodle is primarily developed in Linux using [[Apache]], [[PostgreSQL]]/[[MySQL]]/[[MariaDB]] and [[PHP]] (sometimes known as the LAMP platform). Typically this is also how Moodle is run, although there are other options as long as the software requirements of the [{{Release notes}} release] are met.

If you are installing Moodle in a Windows server, note that from php5.5 onwards, you will also need to have the Visual C++ Redistributable for Visual Studio 2012 installed from:
http://www.microsoft.com/en-us/download/details.aspx?id=30679 Visual C++] ( x86 or x64)

The basic requirements for Moodle are as follows:

=== Hardware ===
* Disk space: 200MB for the Moodle code, plus as much as you need to store content. 5GB is probably a realistic minimum.
* Processor: 1GHz (min), 2GHz dual core or more recommended.
* Memory: 512MB (min), 1GB or more is recommended. 8GB plus is likely on a large production server
* Consider separate servers for the web "front ends" and the database. It is much easier to "tune"

All the above requirements will vary depending on specific hardware and software combinations as well as the type of use and load; busy sites may well require additional resources. Further guidance can be found under [[Performance_recommendations|performance recommendations]]. Moodle scales easily by increasing hardware.

For very large sites, you are much better starting with a small pilot and gaining some experience and insight. A "what hardware do I need for 50,000 user?" style post in the forums is highly unlikely to get a useful answer.

=== Software ===

See the [{{Release notes}} release notes] in the dev docs for software requirements.

== Set up your server ==

Depending the use case a Moodle server may be anything from a Desktop PC (e.g. for testing and evaluating) to a rackmounted or [[Server cluster|clustered]] solution. As mentioned above there are lots of possibilities for installing the basic server software, some links and pointers are at [[Installing AMP]], [[Internet_Information_Services|IIS]], [[Nginx]].

It will help hugely, regardless of your deployment choices, if time is taken to understand how to configure the different parts of your software stack (HTTP daemon, database, PHP etc). Do not expect the standard server configuration to be optimal for Moodle. For example, the web server and database servers will almost certainly require tuning to get the best out of Moodle.

If a hosting provider is being used ensure that all Moodle [{{Release notes}}#Server_requirements requirments] (such as PHP version) are met by the hosting platform before attempting the installation. It will help to become familiar with changing settings within the hosting provider's platform (e.g. PHP file upload maximums) as the options and tools provided vary.

== Download and copy files into place ==

'''IMPORTANT: While there are now a number of places you can get the Moodle code (including host provided Moodle installers), you are strongly advised to only obtain Moodle from moodle.org. If you run into problems it will be a great deal easier to support you.'''

You have two options:
* Download your required version from http://moodle.org/downloads and unzip/unpack...
* '''OR''' Pull the code from the Git repository (recommended for developers and also makes upgrading very simple):
<pre>
$ git clone --depth=1 -b MOODLE_{{Version2}}_STABLE git://git.moodle.org/moodle.git
</pre>

Other options you might consider:
''--depth=1'' for shallow cloning (only) latest revision

''--single-branch'' to limit cloning to a single branch, this fetches the Moodle {{Version}} Stable branch (latest weekly build). For a fuller discussion see [[Git for Administrators]].

Either of the above should result in a directory called '''moodle''', containing a number of files and folders.

You can typically place the whole folder in your web server documents directory, in which case the site will be located at '''<nowiki>http://yourwebserver.com/moodle</nowiki>''', or you can copy all the contents straight into the main web server documents directory, in which case the site will be simply '''<nowiki>http://yourwebserver.com</nowiki>'''. See the documentation for your system and/or web server if you are unsure.

:''Tip:'' If you are downloading Moodle to your local computer and then uploading it to your hosted web site, if possible upload the compressed file and decompress at the remote end (check your 'file manager'). Failing that, watch FTP progress carefully for errors or missed files.

* '''Secure the Moodle files:''' It is vital that the files are not writeable by the web server user. For example, on Unix/Linux (as root):
<pre>
# chown -R root /path/to/moodle
# chmod -R 0755 /path/to/moodle
# find /path/to/moodle -type f -exec chmod 0644 {} \;
</pre>
(files are owned by the administrator/superuser and are only writeable by them - readable by everyone else)

The third command finds all the regular files and executes the chmod command 0644 on them.

If you want to use the built-in plugin installer you need to make the directory writable by web server user. It is strongly recommended to use ACL when your server supports it, for example if your Apache server uses account www-data:

<pre>
# chmod -R +a "www-data allow read,delete,write,append,file_inherit,directory_inherit" /path/to/moodle
</pre>

The effect of the previous command is to allow the Apache user account (www-data in this case) to access and change files within the moodle site. Many people would consider this a brave move for a new site admin to implement. In a new moodle you can safely leave this out. A default Ubuntu install does not have the +a option for the chmod command anyway. The +a attribute is an ACL (Access Control List) facility which allows you to set per user access for individual files. For example, OSX has this by default.

== Create an empty database ==

Next create a new, empty database for your installation. You need to find and make a note of following information for use during the final installation stage:
* '''dbhost''' - the database server hostname. Probably ''localhost'' if the database and web server are the same machine, otherwise the name of the database server
* '''dbname''' - the database name. Whatever you called it, e.g. ''moodle''
* '''dbuser''' - the username for the database. Whatever you assigned, e.g. ''moodleuser'' - do not use the root/superuser account. Create a proper account with the minimum permissions needed.
* '''dbpass''' - the password for the above user

If your site is hosted you should find a web-based administration page for databases as part of the control panel (or ask your administrator). For everyone else or for detailed instructions, see the page for your chosen database server:
* [[PostgreSQL]] (recommended)
* [[MariaDB]] (recommended)
* [[MySQL]]
* [[MSSQL]]
* [[Oracle]] (not recommended)

== Create the (''moodledata'') data directory ==

Moodle requires a directory to store all of its files (all your site's uploaded files, temporary data, cache, session data etc.). The web server needs to be able to write to this directory. On larger systems consider how much free space you are going to use when allocating this directory.

Due to the default way Moodle caches data you may have serious performance issues if you use relatively slow storage (e.g. NFS) for this directory. Read the [[Performance_recommendations]] carefully and consider using (e.g.) redis or memcached for [[Caching]].

'''IMPORTANT:''' This directory must '''NOT''' be accessible directly via the web. This would be a serious security hole. Do not try to place it inside your web root or inside your Moodle program files directory. Moodle will not install. It can go anywhere else convenient.

Here is an example (Unix/Linux) of creating the directory and setting the permissions for '''anyone''' on the server to write here. This is only appropriate for Moodle servers that are not shared. Discuss this with your server administrator for better permissions that just allow the web server user to access these files.

<pre>
# mkdir /path/to/moodledata
# chmod 0777 /path/to/moodledata
</pre>

If your server supports ACL it is recommended to set following permissions, for example if your Apache server uses account www-data:
<pre>
# chmod -R +a "www-data allow read,delete,write,append,file_inherit,directory_inherit" /path/to/moodledata
</pre>
If you are planning to execute PHP scripts from the command line you should set the same permissions for the current user:
<pre>
$ sudo chmod -R +a "`whoami` allow read,delete,write,append,file_inherit,directory_inherit" /path/to/moodledata
</pre>

==== Securing moodledata in a web directory ====

If you are using a hosted site and you have no option but to place 'moodledata' in a web accessible directory. You may be able to secure it by creating an .htaccess file in the 'moodledata' directory. This does not work on all systems - see your host/administrator. Create a file called .htaccess containing only the following lines:
<pre>
order deny,allow
deny from all
</pre>

== Start Moodle install ==
It's now time to run the installer to create the database tables and configure your new site. The recommended method is to use the command line installer. If you cannot do this for any reason (e.g. on a Windows server) the web based installer is still available.

=== Command line installer ===

It's best to run the command line as your system's web user. You need to know what that is - see your system's documentation (e.g. Ubuntu/Debian is 'www-data', Centos is 'apache')

* Example of using the command-line (as root - substitute 'www-data' for your web user):
<pre>
# chown www-data /path/to/moodle
# cd /path/to/moodle/admin/cli
# sudo -u www-data /usr/bin/php install.php
# chown -R root /path/to/moodle
</pre>
The chowns allow the script to write a new config.php file. More information about the options can be found using
<pre>
# php install.php --help
</pre>

You will be asked for other settings that have not been discussed on this page - if unsure just accept the defaults. For a full discussion see [[Administration via command line]]

=== Web based installer ===

For ease of use you can install Moodle via the web. We recommend configuring your web server so that the page is not publicly accessible until the installation is complete.

To run the web installer script, just go to your Moodle's main URL using a web browser.

The installation process will take you through a number of pages. You should be asked to confirm the copyright, see the database tables being created, supply administrator account details and supply the site details. The database creation can take some time - please be patient. You should eventually end up at the Moodle front page with an invitation to create a new course.

It is very likely that you will be asked to download the new config.php file and upload it to your Moodle installation - just follow the on-screen instructions.

==Final configuration==

=== Settings within Moodle ===
There are a number of options within the Moodle Site Administration screens (accessible from the 'Site administration' tab in the 'Administration' block. Here are a few of the more important ones that you will probably want to check:
* ''Administration > Site administration > Plugins > Message Outputs > Email'': Set your smtp server and authentication if required (so your Moodle site can send emails). The support contact for your site is also set on this page.
* ''Administration > Site administration > Server > System paths'': Set the paths to du, dot and aspell binaries.
* ''Administration > Site administration > Server > HTTP'': If you are behind a firewall you may need to set your proxy credentials in the 'Web proxy' section.
* ''Administration > Site administration > Location > Update timezones'': Run this to make sure your timezone information is up to date. (more info [[Location]])
** [http://php.net/manual/en/timezones.php Set server's local timezone] inside <tt>php.ini</tt> (should probably be inside <tt>/etc/php.ini</tt> or <tt>/etc/php.d/date.ini</tt>, depending on the underline OS):
**: <code ini>[Date]
; Defines the default timezone used by the date functions
date.timezone = "YOUR LOCAL TIMEZONE"</code>

=== Remaining tasks ===

* '''Configure Cron''': Moodle's background tasks (e.g. sending out forum emails and performing course backups) are performed by a script which you can set to execute at specific times of the day. This is known as a cron script. Please refer to the [[Cron|Cron instructions]].
* '''Set up backups''': See [[Site backup]] and [[Automated course backup]].
* '''Check mail works''': [[Add a new user|Create a test user]] with a valid email address and [[message|send them a message]]. Do they receive an email copy of the message? If not, check the settings in ''Settings > Site administration > Plugins > Message outputs > Email''. Don't be tempted to skip this step (clue: email is used to recover lost passwords, including the administrator password when you forget it!)
* '''Secure your Moodle site''': Read the [[Security recommendations]].
*'''Increasing the maximum upload size''' See [[Installation FAQ]] Maximum upload file size - how to change it?

=== Installation is complete :) ===

* Create a new course: You can now access Moodle through your web browser (using the same URL as you set during the install process), log in as your admin user and creatse a new course. See [[Adding a new course|create a new course]].

=== If something goes wrong... ===

Here are some things you should try...

* Check the [[Installation FAQ]]
* Check your file permissions carefully. Can your web server read (but not write) the Moodle program files? Can your web server read and write your Moodle data directory? If you don't fully understand how file ownership and permissions work on your operating system it would be time very well spent to find out.
* Check your database permissions. Have you set up your database user with the correct rights and permissions for your configuration (especially if the web server and database server are different machines)?
* Create your [[Configuration file]] (config.php) by hand. Copy config-dist.php (in the root of the Moodle program directory) to config.php, edit it and set your database/site options there. Installation will continue from the right place.
* Once you have a config.php (see previous tip) you can edit it to turn on debugging (in section 8). This may give you extra information to help track down a problem. If you have access, check your web server error log(s).
* Re-check your php.ini / .htaccess settings. Are they appropriate (e.g. memory_limit), did you edit the correct php.ini / .htaccess file and (if required) did you re-start the web server after making changes?
* Did you include any non-core (optional) plugins, themes or other code before starting the installation script? If so, remove it and try again (it may be broken or incompatible).
* Explain your problem in the [http://moodle.org/mod/forum/view.php?id=28 Installation problems forum]. '''PLEASE''' list your software versions; explain what you did, what happened and what error messages you saw (if any); explain what you tried. There is no such thing as 'nothing', even a blank page is something!

== Platform specific instructions ==

'''Note:''' Much of this information is provided by the community. It may not have been checked and may be out of date. Please read in conjunction with the above installation instructions.

* [[Windows installation]]
** [[Installing Moodle on SmarterASP.NET]]
* [[Unix or Linux Installation]]
* [[Mac Installation]]
* [[Amazon EC2 Cloud Services Installation]]

== See also ==
* [http://www.slideshare.net/gb2048/my-own-moodle Slideshare presentation by Gareth Barnard on installing a local installation of Moodle] and accompanying [https://drive.google.com/folderview?id=0B17B0rYH2zERU21sQnVweUZCUFk&usp=sharing help guides]
* [http://moodle.org/mod/forum/discuss.php?d=182086 New Video Tutorial- How to Install Moodle on Shared Hosting via cPanel (Not Fantastico)]
* [http://moodle.org/mod/forum/discuss.php?d=199542 Video Tutorial - Install Moodle on a Virtual Box from scratch]

[[es:Instalaci%C3%B3n_de_moodle]]
[[de:Installation von Moodle]]
[[fr:Installation de Moodle]]
[[ja:Moodleのインストール]]

Installing Moodle

2017-08-11T09:38:19Z

Howardsmiller: /* Create the (moodledata) data directory */

{{Template:Installing Moodle}}
''This page explains how to install Moodle. If you are an expert and/or in a hurry try [[Installation Quickstart]].''

If you just want to try Moodle on a standalone machine there are 'one-click' installers for Windows (see [[Complete install packages for Windows]]) and for OSX (see [[Complete Install Packages for Mac OS X]]) or [[ install on OS X]]. These are unsuitable for production servers.

== Requirements ==

Moodle is primarily developed in Linux using [[Apache]], [[PostgreSQL]]/[[MySQL]]/[[MariaDB]] and [[PHP]] (sometimes known as the LAMP platform). Typically this is also how Moodle is run, although there are other options as long as the software requirements of the [{{Release notes}} release] are met.

If you are installing Moodle in a Windows server, note that from php5.5 onwards, you will also need to have the Visual C++ Redistributable for Visual Studio 2012 installed from:
http://www.microsoft.com/en-us/download/details.aspx?id=30679 Visual C++] ( x86 or x64)

The basic requirements for Moodle are as follows:

=== Hardware ===
* Disk space: 200MB for the Moodle code, plus as much as you need to store content. 5GB is probably a realistic minimum.
* Processor: 1GHz (min), 2GHz dual core or more recommended.
* Memory: 512MB (min), 1GB or more is recommended. 8GB plus is likely on a large production server
* Consider separate servers for the web "front ends" and the database. It is much easier to "tune"

All the above requirements will vary depending on specific hardware and software combinations as well as the type of use and load; busy sites may well require additional resources. Further guidance can be found under [[Performance_recommendations|performance recommendations]]. Moodle scales easily by increasing hardware.

For very large sites, you are much better starting with a small pilot and gaining some experience and insight. A "what hardware do I need for 50,000 user?" style post in the forums is highly unlikely to get a useful answer.

=== Software ===

See the [{{Release notes}} release notes] in the dev docs for software requirements.

== Set up your server ==

Depending the use case a Moodle server may be anything from a Desktop PC (e.g. for testing and evaluating) to a rackmounted or [[Server cluster|clustered]] solution. As mentioned above there are lots of possibilities for installing the basic server software, some links and pointers are at [[Installing AMP]], [[Internet_Information_Services|IIS]], [[Nginx]].

It will help hugely, regardless of your deployment choices, if time is taken to understand how to configure the different parts of your software stack (HTTP daemon, database, PHP etc). Do not expect the standard server configuration to be optimal for Moodle. For example, the web server and database servers will almost certainly require tuning to get the best out of Moodle.

If a hosting provider is being used ensure that all Moodle [{{Release notes}}#Server_requirements requirments] (such as PHP version) are met by the hosting platform before attempting the installation. It will help to become familiar with changing settings within the hosting provider's platform (e.g. PHP file upload maximums) as the options and tools provided vary.

== Download and copy files into place ==

'''IMPORTANT: While there are now a number of places you can get the Moodle code (including host provided Moodle installers), you are strongly advised to only obtain Moodle from moodle.org. If you run into problems it will be a great deal easier to support you.'''

You have two options:
* Download your required version from http://moodle.org/downloads and unzip/unpack...
* '''OR''' Pull the code from the Git repository (recommended for developers and also makes upgrading very simple):
<pre>
$ git clone --depth=1 -b MOODLE_{{Version2}}_STABLE git://git.moodle.org/moodle.git
</pre>

Other options you might consider:
''--depth=1'' for shallow cloning (only) latest revision

''--single-branch'' to limit cloning to a single branch, this fetches the Moodle {{Version}} Stable branch (latest weekly build). For a fuller discussion see [[Git for Administrators]].

Either of the above should result in a directory called '''moodle''', containing a number of files and folders.

You can typically place the whole folder in your web server documents directory, in which case the site will be located at '''<nowiki>http://yourwebserver.com/moodle</nowiki>''', or you can copy all the contents straight into the main web server documents directory, in which case the site will be simply '''<nowiki>http://yourwebserver.com</nowiki>'''. See the documentation for your system and/or web server if you are unsure.

:''Tip:'' If you are downloading Moodle to your local computer and then uploading it to your hosted web site, if possible upload the compressed file and decompress at the remote end (check your 'file manager'). Failing that, watch FTP progress carefully for errors or missed files.

* '''Secure the Moodle files:''' It is vital that the files are not writeable by the web server user. For example, on Unix/Linux (as root):
<pre>
# chown -R root /path/to/moodle
# chmod -R 0755 /path/to/moodle
# find /path/to/moodle -type f -exec chmod 0644 {} \;
</pre>
(files are owned by the administrator/superuser and are only writeable by them - readable by everyone else)

The third command finds all the regular files and executes the chmod command 0644 on them.

If you want to use the built-in plugin installer you need to make the directory writable by web server user. It is strongly recommended to use ACL when your server supports it, for example if your Apache server uses account www-data:

<pre>
# chmod -R +a "www-data allow read,delete,write,append,file_inherit,directory_inherit" /path/to/moodle
</pre>

The effect of the previous command is to allow the Apache user account (www-data in this case) to access and change files within the moodle site. Many people would consider this a brave move for a new site admin to implement. In a new moodle you can safely leave this out. A default Ubuntu install does not have the +a option for the chmod command anyway. The +a attribute is an ACL (Access Control List) facility which allows you to set per user access for individual files. For example, OSX has this by default.

== Create an empty database ==

Next create a new, empty database for your installation. You need to find and make a note of following information for use during the final installation stage:
* '''dbhost''' - the database server hostname. Probably ''localhost'' if the database and web server are the same machine, otherwise the name of the database server
* '''dbname''' - the database name. Whatever you called it, e.g. ''moodle''
* '''dbuser''' - the username for the database. Whatever you assigned, e.g. ''moodleuser'' - do not use the root/superuser account. Create a proper account with the minimum permissions needed.
* '''dbpass''' - the password for the above user

If your site is hosted you should find a web-based administration page for databases as part of the control panel (or ask your administrator). For everyone else or for detailed instructions, see the page for your chosen database server:
* [[PostgreSQL]] (recommended)
* [[MariaDB]] (recommended)
* [[MySQL]]
* [[MSSQL]]
* [[Oracle]] (not recommended)

== Create the (''moodledata'') data directory ==

Moodle requires a directory to store all of its files (all your site's uploaded files, temporary data, cache, session data etc.). The web server needs to be able to write to this directory. On larger systems consider how much free space you are going to use when allocating this directory.

Due to the default way Moodle caches data you may have serious performance issues if you use relatively slow storage (e.g. NFS) for this directory. Read the [[Performance_recommendations]] carefully and consider using (e.g.) redis or memcached for [[Caching]].

'''IMPORTANT:''' This directory must '''NOT''' be accessible directly via the web. This would be a serious security hole. Do not try to place it inside your web root or inside your Moodle program files directory. Moodle will not install. It can go anywhere else convenient.

Here is an example (Unix/Linux) of creating the directory and setting the permissions for '''anyone''' on the server to write here. This is only appropriate for Moodle servers that are not shared. Discuss this with your server administrator for better permissions that just allow the web server user to access these files.

<pre>
# mkdir /path/to/moodledata
# chmod 0777 /path/to/moodledata
</pre>

If your server supports ACL it is recommended to set following permissions, for example if your Apache server uses account www-data:
<pre>
# chmod -R +a "www-data allow read,delete,write,append,file_inherit,directory_inherit" /path/to/moodledata
</pre>
If you are planning to execute PHP scripts from the command line you should set the same permissions for the current user:
<pre>
$ sudo chmod -R +a "`whoami` allow read,delete,write,append,file_inherit,directory_inherit" /path/to/moodledata
</pre>

==== Securing moodledata in a web directory ====

If you are using a hosted site and you have no option but to place 'moodledata' in a web accessible directory. You may be able to secure it by creating an .htaccess file in the 'moodledata' directory. This does not work on all systems - see your host/administrator. Create a file called .htaccess containing only the following lines:
<pre>
order deny,allow
deny from all
</pre>

== Start Moodle install ==
It's now time to run the installer to create the database tables and configure your new site. The recommended method is to use the command line installer. If you cannot do this for any reason (e.g. on a Windows server) the web based installer is still available.

=== Command line installer ===

It's best to run the command line as your system's web user. You need to know what that is - see your system's documentation (e.g. Ubuntu/Debian is 'www-data', Centos is 'apache')

* Example of using the command-line (as root - substitute 'www-data' for your web user):
<pre>
# chown www-data /path/to/moodle
# cd /path/to/moodle/admin/cli
# sudo -u www-data /usr/bin/php install.php
# chown -R root /path/to/moodle
</pre>
The chowns allow the script to write a new config.php file. More information about the options can be found using
<pre>
# php install.php --help
</pre>

You will be asked for other settings that have not been discussed on this page - if unsure just accept the defaults. For a full discussion see [[Administration via command line]]

=== Web based installer ===

For ease of use you can install Moodle via the web. We recommend configuring your web server so that the page is not publicly accessible until the installation is complete.

To run the web installer script, just go to your Moodle's main URL using a web browser.

The installation process will take you through a number of pages. You should be asked to confirm the copyright, see the database tables being created, supply administrator account details and supply the site details. The database creation can take some time - please be patient. You should eventually end up at the Moodle front page with an invitation to create a new course.

It is very likely that you will be asked to download the new config.php file and upload it to your Moodle installation - just follow the on-screen instructions.

==Final configuration==

=== Settings within Moodle ===
There are a number of options within the Moodle Site Administration screens (accessible from the 'Site administration' tab in the 'Administration' block. Here are a few of the more important ones that you will probably want to check:
* ''Administration > Site administration > Plugins > Message Outputs > Email'': Set your smtp server and authentication if required (so your Moodle site can send emails). The support contact for your site is also set on this page.
* ''Administration > Site administration > Server > System paths'': Set the paths to du, dot and aspell binaries.
* ''Administration > Site administration > Server > HTTP'': If you are behind a firewall you may need to set your proxy credentials in the 'Web proxy' section.
* ''Administration > Site administration > Location > Update timezones'': Run this to make sure your timezone information is up to date. (more info [[Location]])
** [http://php.net/manual/en/timezones.php Set server's local timezone] inside <tt>php.ini</tt> (should probably be inside <tt>/etc/php.ini</tt> or <tt>/etc/php.d/date.ini</tt>, depending on the underline OS):
**: <code ini>[Date]
; Defines the default timezone used by the date functions
date.timezone = "YOUR LOCAL TIMEZONE"</code>

=== Remaining tasks ===

* '''Configure Cron''': Moodle's background tasks (e.g. sending out forum emails and performing course backups) are performed by a script which you can set to execute at specific times of the day. This is known as a cron script. Please refer to the [[Cron|Cron instructions]].
* '''Set up backups''': See [[Site backup]] and [[Automated course backup]].
* '''Check mail works''': [[Add a new user|Create a test user]] with a valid email address and [[message|send them a message]]. Do they receive an email copy of the message? If not, check the settings in ''Settings > Site administration > Plugins > Message outputs > Email''. Don't be tempted to skip this step (clue: email is used to recover lost passwords, including the administrator password when you forget it!)
* '''Secure your Moodle site''': Read the [[Security recommendations]].
*'''Increasing the maximum upload size''' See [[Installation FAQ]] Maximum upload file size - how to change it?

=== Installation is complete :) ===

* Create a new course: You can now access Moodle through your web browser (using the same URL as you set during the install process), log in as your admin user and creatse a new course. See [[Adding a new course|create a new course]].

=== If something goes wrong... ===

Here are some things you should try...

* Check the [[Installation FAQ]]
* Check your file permissions carefully. Can your web server read (but not write) the Moodle program files? Can your web server read and write your Moodle data directory?
* Check your database permissions. Have you set up your database user with the correct rights and permissions for your configuration (especially if the web server and database server are different machines)?
* Create your [[Configuration file]] (config.php) by hand. Copy config-dist.php (in the root of the Moodle program directory) to config.php, edit it and set your database/site options there. Installation will continue from the right place.
* Once you have a config.php (see previous tip) you can edit it to turn on debugging (in section 8). This may give you extra information to help track down a problem. If you have access, check your web server error log(s).
* Re-check your php.ini / .htaccess settings. Are they appropriate (e.g. memory_limit), did you edit the correct php.ini / .htaccess file and (if required) did you re-start the web server after making changes?
* Did you include any non-core (optional) plugins, themes or other code before starting the installation script? If so, remove it and try again (it may be broken or incompatible).
* Explain your problem in the [http://moodle.org/mod/forum/view.php?id=28 Installation problems forum]. '''PLEASE''' list your software versions; explain what you did, what happened and what error messages you saw (if any); explain what you tried. There is no such thing as 'nothing', even a blank page is something!

== Platform specific instructions ==

'''Note:''' Much of this information is provided by the community. It may not have been checked and may be out of date. Please read in conjunction with the above installation instructions.

* [[Windows installation]]
** [[Installing Moodle on SmarterASP.NET]]
* [[Unix or Linux Installation]]
* [[Mac Installation]]
* [[Amazon EC2 Cloud Services Installation]]

== See also ==
* [http://www.slideshare.net/gb2048/my-own-moodle Slideshare presentation by Gareth Barnard on installing a local installation of Moodle] and accompanying [https://drive.google.com/folderview?id=0B17B0rYH2zERU21sQnVweUZCUFk&usp=sharing help guides]
* [http://moodle.org/mod/forum/discuss.php?d=182086 New Video Tutorial- How to Install Moodle on Shared Hosting via cPanel (Not Fantastico)]
* [http://moodle.org/mod/forum/discuss.php?d=199542 Video Tutorial - Install Moodle on a Virtual Box from scratch]

[[es:Instalaci%C3%B3n_de_moodle]]
[[de:Installation von Moodle]]
[[fr:Installation de Moodle]]
[[ja:Moodleのインストール]]

Cron

2017-04-06T13:55:38Z

Howardsmiller: /* The web based Moodle cron command */

{{Installing Moodle}}
The Moodle 'cron' process is a PHP script (part of the standard Moodle installation) that must be run regularly in the background. The Moodle cron script runs different tasks at differently scheduled intervals.

'''IMPORTANT: Do not skip setting up the cron process on your server for your Moodle. Your site will not work properly without it.'''

It is recommended that ''the cron is run every minute'', as required for asynchronous activity deletion when using the [[Recycle bin|recycle bin]].

The cron program (that runs the Moodle script) is a core part of Unix based systems (including Linux and OSX) being used to run all manner of time-dependent services. On Windows the simplest solution is to create a task in the Windows Task Scheduler and set it to run at regular intervals. On shared hosting, you should find the documentation (or ask support) how cron is configured.

Essentially, the task involves adding a single command to the list of cron activities on your system. On Unix based systems this list is a file called a 'crontab' which all users have.

== General discussion ==

See the later sections for your server type; this section contains some general background information.

There are essentially two steps to implementing cron:
# identifying the correct command to run
# finding the right place on your system to put the command

=== Working out the Moodle cron command ===

Moodle has two different ways to deploy cron which use different scripts within the Moodle install. These are as follows...
# The CLI (command line interpreter) script. This will be at the path <pre>/path/to/moodle/admin/cli/cron.php</pre> If in doubt, this is the correct script to use. This needs to be run by a 'PHP CLI' program on your computer. So the final command may look something like <pre>/usr/bin/php /path/to/moodle/admin/cli/cron.php</pre> You can (and should) try this on your command line to see if it works. '''WARNING: Check your command-line PHP version is compatible with your chosen version of Moodle. The command-line PHP program is different to the one running your web site and is not always the same version.'''
# If, for some reason, you cannot run the CLI script there is the web based script. Note that this is now deprecated and may be removed in future versions. This needs to be run from a web browser and will be accessed via a web url something like '''http://your.moodle.site/admin/cron.php'''. You can find command line based web browser (e.g. wget) so the final command may look like <pre>/usr/bin/wget http://your.moodle.site/admin/cron.php</pre> This has the advantage that it can be run from *anywhere*. If you can't get cron to work on your machine it can be run somewhere else.

===The web based Moodle cron command===
* If you have a choice, do not use the web based cron. It is likely to be removed in a future Moodle version.
* From Moodle 2.9 onwards, the cron job can no longer be run from web by default. You will get an error message:
!!! Sorry, internet access to this page has been disabled by the administrator. !!!
* You can change this in ' Dashboard ► Site administration ► Security ► Site policies ' by deselecting 'Cron execution via command line only'.
** You will be warned that 'Running the cron from a web browser can expose privileged information to anonymous users. Thus it is recommended to only run the cron from the command line or set a cron password for remote access.'
** You can then write a 'Cron password for remote access'. If this field is left empty, no password is required.
** This means that the cron.php script cannot be run from a web browser without supplying the password using the following form of URL:
http://site.example.com/admin/cron.php?password=opensesame

=== Finding the right place to put the command ===

This really does depend on the system you are using and you should find and read the documentation for your platform or hosting. In most cases getting the Moodle cron to run consists of establishing the correct command (above) and then adding it, and the time to run the command, to some sort of file. This might be either through a specific user interface or by editing the file directly.

If using the CLI version you also need to make sure that the cron process is run as the correct user. This is not an issue with the web version.

Example... installing cron on Ubuntu/Debian Linux. Assuming logged in as root..

''use the crontab command to open a crontab editor window for the www-data user. This is the user that Apache (the web server) runs as on Debian based systems''
<pre>
$ crontab -u www-data -e
</pre>
''This will open an editor window. To run the cli cron script every 1 minute, add the line:''
<pre>
*/1 * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php >/dev/null
</pre>
NOTE: the final '''>/dev/null''' sends all the output to the 'bin' and stops you getting an email every 1 minute.

== Setting up cron on your system ==

Choose the information for your server type:

*[[Cron with Unix or Linux]]- Cron services on various UNIX and Linux flavored operating systems.
*[[Cron with Windows OS]] - Cron services in Windows
*''Apple OSX'' - use the built-in 'crontab' service which is exactly the same as [[Cron with Unix or Linux]]. However, you might want to do it the 'Apple way' using launchd - see [[Cron with MAC OS X]]
*[[Cron with web hosting services]]- Cron services in various web hosting examples.

Here are some more instructions for specific hosts (please check that these are up to date):

*[[Cron on 1and1 shared servers]]

== Using third party cron service ==

Besides using cron hosted on your own server, you may use third party cron service (usually called webcron):

*[https://cron-job.org/ cron-job.org] is a free service. (1Minute cron is possible)

*[https://www.easycron.com EasyCron] - A webcron service provider that eliminates the need of crontab or other task schedulers to set cron job.

=== Cron settings in Moodle ===

An admin can set cron execution via command line only or a cron password for remote access in ''Administration > Site administration > Security > Site policies''.

===Remote cron===
Using the 'web based' version of cron it is perfectly ok to place the cron process on a different machine to the Moodle server. For example, the cron service on a Unix server can invoke the cron web 'page' on a Windows based Moodle server.

==Scheduling tasks==
An administrator can schedule cron tasks very precisely from Administration > Site administration > Server > Scheduled tasks, see [[Scheduled tasks]]

==Running cron for several Moodle servers==
* Tasks can run in parallel and processes use locking to prevent tasks from running at the same time which allows cron to be triggered from multiple web servers that serve the same Moodle instance.

* If you are running different Moodle instances on the same server, then each Moodle instance needs a cron job. (Even a single Apache web server can run different Moodle instances on different domains by using its virtual hosts capability [https://httpd.apache.org/docs/2.2/vhosts/index.html https://httpd.apache.org/docs/2.2/vhosts/index.html].)

== Debugging Scheduled Tasks ==

Sometimes, a particular cron task may not be working correctly. In Moodle versions before 2.7 - any cron task that was throwing exceptions would prevent the rest of cron from running. The only way to monitor if cron was completing each time, was to add some automated checking of the output of running cron (e.g. searching for the string "Cron completed at ").

In Moodle 2.7 and later, a single failing scheduled task will not prevent the remaining tasks from completing. When any single scheduled task fails, it is marked as a failure, and scheduled to be reattempted. If the task keeps failing, the next scheduled time will be backed off until it is attempted at most once every 24 hours. But checking the [[Scheduled tasks]] admin page, you can see if any task is currently failing (it will have a non-zero fail delay - which is the number of seconds to wait before reattempting a failed task). A simple way to debug a failing task, is to run it immediately using the [[Administration via command line#Scheduled_tasks|cli scheduled task runner]] and monitor the output.

==See also==

* [[Scheduled tasks]]
* [http://en.wikipedia.org/wiki/Cron Wikipedia article on cron function]

Forum discussions:
*[http://moodle.org/mod/forum/discuss.php?d=139263#p609060 How to log the output of a Scheduled Task on Windows] - this discussion explains a nice trick that can be very useful when you are experiencing problems with your Windows Scheduled Task and you need to log the output of the Scheduled Task to a log file.
*[https://moodle.org/mod/forum/discuss.php?d=324443 Cron Lock]

[[es:Cron]]
[[fr:Cron]]
[[ja:Cron]]
[[de:Cron-Job]]

Cron

2017-04-06T13:54:54Z

Howardsmiller: /* Working out the Moodle cron command */

{{Installing Moodle}}
The Moodle 'cron' process is a PHP script (part of the standard Moodle installation) that must be run regularly in the background. The Moodle cron script runs different tasks at differently scheduled intervals.

'''IMPORTANT: Do not skip setting up the cron process on your server for your Moodle. Your site will not work properly without it.'''

It is recommended that ''the cron is run every minute'', as required for asynchronous activity deletion when using the [[Recycle bin|recycle bin]].

The cron program (that runs the Moodle script) is a core part of Unix based systems (including Linux and OSX) being used to run all manner of time-dependent services. On Windows the simplest solution is to create a task in the Windows Task Scheduler and set it to run at regular intervals. On shared hosting, you should find the documentation (or ask support) how cron is configured.

Essentially, the task involves adding a single command to the list of cron activities on your system. On Unix based systems this list is a file called a 'crontab' which all users have.

== General discussion ==

See the later sections for your server type; this section contains some general background information.

There are essentially two steps to implementing cron:
# identifying the correct command to run
# finding the right place on your system to put the command

=== Working out the Moodle cron command ===

Moodle has two different ways to deploy cron which use different scripts within the Moodle install. These are as follows...
# The CLI (command line interpreter) script. This will be at the path <pre>/path/to/moodle/admin/cli/cron.php</pre> If in doubt, this is the correct script to use. This needs to be run by a 'PHP CLI' program on your computer. So the final command may look something like <pre>/usr/bin/php /path/to/moodle/admin/cli/cron.php</pre> You can (and should) try this on your command line to see if it works. '''WARNING: Check your command-line PHP version is compatible with your chosen version of Moodle. The command-line PHP program is different to the one running your web site and is not always the same version.'''
# If, for some reason, you cannot run the CLI script there is the web based script. Note that this is now deprecated and may be removed in future versions. This needs to be run from a web browser and will be accessed via a web url something like '''http://your.moodle.site/admin/cron.php'''. You can find command line based web browser (e.g. wget) so the final command may look like <pre>/usr/bin/wget http://your.moodle.site/admin/cron.php</pre> This has the advantage that it can be run from *anywhere*. If you can't get cron to work on your machine it can be run somewhere else.

===The web based Moodle cron command===
* From Moodle 2.9 onwards, the cron job can no longer be run from web by default. You will get an error message:
!!! Sorry, internet access to this page has been disabled by the administrator. !!!
* You can change this in ' Dashboard ► Site administration ► Security ► Site policies ' by deselecting 'Cron execution via command line only'.
** You will be warned that 'Running the cron from a web browser can expose privileged information to anonymous users. Thus it is recommended to only run the cron from the command line or set a cron password for remote access.'
** You can then write a 'Cron password for remote access'. If this field is left empty, no password is required.
** This means that the cron.php script cannot be run from a web browser without supplying the password using the following form of URL:
http://site.example.com/admin/cron.php?password=opensesame

=== Finding the right place to put the command ===

This really does depend on the system you are using and you should find and read the documentation for your platform or hosting. In most cases getting the Moodle cron to run consists of establishing the correct command (above) and then adding it, and the time to run the command, to some sort of file. This might be either through a specific user interface or by editing the file directly.

If using the CLI version you also need to make sure that the cron process is run as the correct user. This is not an issue with the web version.

Example... installing cron on Ubuntu/Debian Linux. Assuming logged in as root..

''use the crontab command to open a crontab editor window for the www-data user. This is the user that Apache (the web server) runs as on Debian based systems''
<pre>
$ crontab -u www-data -e
</pre>
''This will open an editor window. To run the cli cron script every 1 minute, add the line:''
<pre>
*/1 * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php >/dev/null
</pre>
NOTE: the final '''>/dev/null''' sends all the output to the 'bin' and stops you getting an email every 1 minute.

== Setting up cron on your system ==

Choose the information for your server type:

*[[Cron with Unix or Linux]]- Cron services on various UNIX and Linux flavored operating systems.
*[[Cron with Windows OS]] - Cron services in Windows
*''Apple OSX'' - use the built-in 'crontab' service which is exactly the same as [[Cron with Unix or Linux]]. However, you might want to do it the 'Apple way' using launchd - see [[Cron with MAC OS X]]
*[[Cron with web hosting services]]- Cron services in various web hosting examples.

Here are some more instructions for specific hosts (please check that these are up to date):

*[[Cron on 1and1 shared servers]]

== Using third party cron service ==

Besides using cron hosted on your own server, you may use third party cron service (usually called webcron):

*[https://cron-job.org/ cron-job.org] is a free service. (1Minute cron is possible)

*[https://www.easycron.com EasyCron] - A webcron service provider that eliminates the need of crontab or other task schedulers to set cron job.

=== Cron settings in Moodle ===

An admin can set cron execution via command line only or a cron password for remote access in ''Administration > Site administration > Security > Site policies''.

===Remote cron===
Using the 'web based' version of cron it is perfectly ok to place the cron process on a different machine to the Moodle server. For example, the cron service on a Unix server can invoke the cron web 'page' on a Windows based Moodle server.

==Scheduling tasks==
An administrator can schedule cron tasks very precisely from Administration > Site administration > Server > Scheduled tasks, see [[Scheduled tasks]]

==Running cron for several Moodle servers==
* Tasks can run in parallel and processes use locking to prevent tasks from running at the same time which allows cron to be triggered from multiple web servers that serve the same Moodle instance.

* If you are running different Moodle instances on the same server, then each Moodle instance needs a cron job. (Even a single Apache web server can run different Moodle instances on different domains by using its virtual hosts capability [https://httpd.apache.org/docs/2.2/vhosts/index.html https://httpd.apache.org/docs/2.2/vhosts/index.html].)

== Debugging Scheduled Tasks ==

Sometimes, a particular cron task may not be working correctly. In Moodle versions before 2.7 - any cron task that was throwing exceptions would prevent the rest of cron from running. The only way to monitor if cron was completing each time, was to add some automated checking of the output of running cron (e.g. searching for the string "Cron completed at ").

In Moodle 2.7 and later, a single failing scheduled task will not prevent the remaining tasks from completing. When any single scheduled task fails, it is marked as a failure, and scheduled to be reattempted. If the task keeps failing, the next scheduled time will be backed off until it is attempted at most once every 24 hours. But checking the [[Scheduled tasks]] admin page, you can see if any task is currently failing (it will have a non-zero fail delay - which is the number of seconds to wait before reattempting a failed task). A simple way to debug a failing task, is to run it immediately using the [[Administration via command line#Scheduled_tasks|cli scheduled task runner]] and monitor the output.

==See also==

* [[Scheduled tasks]]
* [http://en.wikipedia.org/wiki/Cron Wikipedia article on cron function]

Forum discussions:
*[http://moodle.org/mod/forum/discuss.php?d=139263#p609060 How to log the output of a Scheduled Task on Windows] - this discussion explains a nice trick that can be very useful when you are experiencing problems with your Windows Scheduled Task and you need to log the output of the Scheduled Task to a log file.
*[https://moodle.org/mod/forum/discuss.php?d=324443 Cron Lock]

[[es:Cron]]
[[fr:Cron]]
[[ja:Cron]]
[[de:Cron-Job]]

Upload users

2017-03-16T14:30:36Z

Howardsmiller: /* Hints */

{{Accounts}}
==Uploading users via text file==

There are many options for uploading information (fields associated with a user) with this method: from enrolling users in multiple courses with course specific [[Roles|roles]] to updating user information in the [[User profile]] to deleting users from the site.

''Tip:'' It is usually not necessary to upload users in bulk with Upload users. To keep maintenance work down you should first explore forms of authentication that do not require manual maintenance, such as [[External database authentication|connecting to existing external databases]] or letting the users create their own accounts ([[Self enrolment]]). See [[Authentication]] for more information.

==File formats for upload users file==
The upload users file has fields separated by a comma (or other delimiter) ONLY - no space. The first line contains the valid field names. The rest of the lines (records) contain information about each user.

''Tip:'' Avoid special characters in field information like quotes or other commas. Test a file with only one record before a large upload.

''Tip:'' You can use a spread sheet program to create the file with the required columns and fields. Then save the file as "CSV (comma delimited)". These files can be opened with simple text editors (eg, [https://notepad-plus-plus.org/ Notepad++]) for verification.

===Valid upload file for testing===
Here is an example of a simple valid upload file:
(Column headers on the first line of the file are only highlighted in bold in this example to distinguish it from the rest of the of the data/user details)

'''username,password,firstname,lastname,email,course1,group1,cohort1'''
jonest,verysecret,Tom,Jones,jonest@someplace.edu,math102,Section 1,year 3
reznort,somesecret,Trent,Reznor,reznort@someplace.edu,math102,Section 3,year 4

===Fields that can be included===
''Tip:'' We strongly recommend that you test a file that contains fields you proposed to use with one user before attempting a file upload for the first time.

*'''Required fields''':
:<code>username,firstname,lastname,email</code>
:Validity checks are performed for:
#<code>username</code> can only contain alphabetical '''lowercase''' letters , numbers, hypen '-', underscore '_', period '.', or at-sign '@'
#<code>email</code> is in the form: ''name@example.com'' .

*'''Password field''': "password" field is optional if "Create password if needed" setting is chosen (default).
**If included, values should meet the requirements for the site's [[Site_policies#Password_policy|Password policy]]. To force password change for a particular user, set the password field to <code>changeme</code>.
**If omitted, a password will be generated for each user (during the next Cron job) and welcome e-mails sent out.
**Note: the text for the welcome e-mail is in the language settings. Please refer to this [https://moodle.org/mod/forum/discuss.php?d=210359&parent=917138 forum thread]for details.

*'''Optional fields''': To provide values other than the default include one or more of these
:<code>institution,department,city,country,lang,auth,timezone,idnumber,icq,phone1,phone2,address,url,description,mailformat,maildisplay,htmleditor,autosubscribe</code>
*'''[[Additional name fields]]'''
*Country- use a country TWO LETTER CODE
* The auth field must be used if the site uses an alternative authentication method, such as LDAP, as otherwise the authentication method will default to manual and users using a different auth method won't be able to log in.
*Some fields have a maximum number of characters that are allowed (notably institution should be '''at most 40 characters''' long). See hints below.
*Maildisplay, htmleditor and autosubscribe can be set from an import screen.

*'''Custom profile field names''': (Optional). xxxxx is the real custom user profile field name (i.e. the unique shortname)
:<code>profile_field_xxxxx</code>
: Create the custom fields BEFORE importing. Use the standard header. The "shortname" for your custom field is xxxxx (NB the shortname must be all lowercase, otherwise won't be recognised). The first record must include "profile_field_xxxxx".

:'''Example''': To create a custom field "genre", you must write a shortname "genre" in the new field, and write "profile_field_genre" in the header of the .csv file.

: For custom profile fields that are a menu, use the corresponding value.

For custom profile fields that are dates, use the ISO standard format YYYY-MM-DD, eg. 2014-06-19 which will then be properly localized in the interfaced.

:'''Example''': A custom field 'Department' with one of three values 'HR', 'Marketing' or 'Training'. Just insert one of those three words (e.g. 'Training') as the value for that field.

*'''Special fields''': Used for changing of usernames or deleting of users
:<code>oldusername</code>, <code>deleted</code>, <code>suspended</code>

*'''Enrolment fields''': (Optional):
:<code>course1,type1,role1,group1,enrolperiod1,enrolstatus1,course2,type2,role2,group2,enrolperiod2,enrolstatus2</code> etc.

:* Header fields must have a numeric suffix such that <code>type1</code>,<code>role1</code>,<code>group1</code>,<code>enrolperiod1</code> and <code>enrolstatus1</code> all apply to <code>course1</code> for course<code>1</code> to course<code>n</code>.
:*<code>course</code> is the "shortname" of the course, if present the user will be enrolled in that course.
:* <code>type</code> sets the role to be used for the enrolment. A value of <code>1</code> is default course role, <code>2</code> is legacy Teacher role and <code>3</code> is legacy Non-editing Teacher.
:* <code>role</code> may be used to specify roles directly, using either role short name or id (numeric names of roles are not supported).
:* <code>group</code> may be used to assign users to groups in course, using name or id (numeric group names are not supported)
:* <code>enrolperiod</code> may be used to set the enrolment duration, in days, for each course.
:* <code>enrolstatus</code> can suspend users from a course when set to 1 or left blank for enrolled. If a user is previously set as inactive / suspended then a value of 0 will unsuspend them.

*'''Cohort field''': (Optional):
:<code>cohort1</code>

:Internal cohort id numbers or non-numeric Cohort IDs of existing cohorts must be used; names are not allowed.
*'''mnethostid''' (Optional)

Existing [[MNet]]users can be added to courses, groups or cohorts as below:
#enrolling to courses: username+mnethostid+course required
# adding to group: username+mnethostid+course+group required
#adding to cohort: username+mnethostid+cohort required
#suspending/reviving accounts: username+mnethostid+suspended required
All other operations are ignored. You can not add users, delete them or update them (such as change names or email, profile fields, etc.)

*'''System role''' (Optional)
:<code>sysrole1,sysrole2,sysrole3</code> etc
Users may be uploaded to a system role (usually Manager or Course creator) by entering the shortname of that role. Other roles can only be uploaded if they have already been assigned in the 'system' context. See [[Creating custom roles]]. Multiple roles can be assigned using <code>sysrole2</code>, <code>sysrole3</code>, etc. fields. Note that the number suffix in no way relates to the number suffixes on the enrolment fields. The numbers must go up in sequence starting at 1.

*'''Unassigning roles'''
Users can also be removed from a given system role by entering the shortname of that role prefixed with a minus symbol: '-'. If the user is currently assigned to that role, they are removed from it. If the user is not currently assigned to that system role, the field value is ignored. However, the field value must refer to a system role that does exist on the system, otherwise an error will occur.
[[File:GlobalRoles1.png|thumb|500px|center|Example of a file for uploading users with global/system roles]]

Commas within a field must be encoded as &#44 - the script will decode these back to commas.

For Boolean fields, use <code>0</code> for false and <code>1</code> for true.

To prevent users from receiving a large number of emails from courses or forced subscription forums use the '''maildigest'''. The options for this field are 0 = No digest, 1 = Complete digest and 2 = Digest with just subjects.
==Upload user process==

# Create file for uploading
# Go to ''Site administration > Users > Accounts > Upload users''
# Add file to upload
# Upload users preview - check settings and default user profile settings
# Upload users preview - click "Upload users"
# Upload users results - shows list of users, exceptions made in upload and summary of number of users
# Upload users results - click "Continue"
# Returns to Upload users screen

==Updating users preview==
There are various settings to better control the desired upload behaviour. These settings are found on the "Upload users preview" page.

'''Warning''': errors updating existing accounts can affect your users badly. '''''Be careful''''' when using the options to update.

====Upload type====
The Upload type specifies how to handle existing accounts.
;Add new only, skip existing users : is the default Moodle upload type. It creates a new user account for each new record in the uploaded file. If an existing <code>username</code> is found (i.e., the <code>username</code> in the uploaded file matches an existing <code>username</code>, that record is '''skipped'''. By skipping the existing user account, the data in the existing record is not touched (in contrast to the "Add new and update existing users" option) and a second new user account is '''not''' created (in contrast to the "Add all, append number to usernames if needed" option).
;Add all, append number to usernames if needed : creates a new user account for each record in the uploaded file. If an existing user account is found, a new account will be created with a number appended to the <code>username</code>. For example, if a user account for <code>username</code> 'jsmith' already exists and a new record in the uploaded file contains a record for <code>username</code> 'jsmith' an additional user account is created with a 1 '''appended''' to the <code>username</code> to produce user 'jsmith1'.
;Add new and update existing users : creates a new user account for each new user in the upload file. If an existing user account with the same <code>username</code> is found, the account information is '''updated''' by the data in the uploaded file.
;Update existing users only : ignores any new users found in the upload file and updates the user account if a matching <code>username</code> record is found in the uploaded file.

====New user password====
When creating a new user account Moodle can create a new password (if one is not provided) or require a password in the uploaded file.
;Create password if needed : creates a default password for the new user account if one is not provided in the uploaded file.
;Field required in file : requires that a password be provided in the uploaded file in order. If a password is not provided, an error is generated and the user account is not created.

====Existing user details====
The Existing user details options are only available when the Upload type allows existing user accounts to be updated. It specifies how Moodle should process user detail information for existing users.
;No changes : ignores user detail data in the uploaded and leaves the existing user account data unchanged.
;Override with file : overwrites data in the existing user account with the data provided in the uploaded file.
;Override with file and defaults : overwrites data in the existing user account with data provided in the uploaded file and fills in the default values for existing user details when no data is provided in the uploaded file.
;Fill in missing from file and defaults : adds data in the existing user account with data provided in the uploaded file if the field is empty (does not already contain data) and fills in the default values for existing user details when no data is provided in the uploaded file.

====Existing user password====
The Existing user password option specifies how to handle password data for existing user accounts when Existing user details is set to overwrite data.
;No changes : ignores password field in the uploaded user file and leaves the existing user account password untouched
;Update : overwrites the existing user account password with the password provided in the uploaded file

====Force password change====
The Force password change option specifies when to tag a user account so that the next login attempt will require the user to change the user's password.
;Users having a weak password : If the user account has a weak password as defined by the stie's [[Password_policy#Password_policy|Password policy]] then the user will be forced to change the password during the next login attempt. This option is not shown if there the site does not have a [[Password_policy#Password_policy|Password policy]], in other words <code>$CFG->passwordpolicy</code> must be set to see this option.
;None : None of the users in the uploaded file will be forced to change the password during the user's next login attempt.
;All : All of the users in the uploaded file will be forced to change the password during the user's next login attempt.

====Allow renames====
If the uploaded flie contains the special <code>oldusername</code> field, it is possible to rename a user from the <code>oldusername</code> to a new <code>username</code>. The default setting is to '''not''' allow renames. Keep in mind that renaming a user will require the user to use the new username when logging in.
;No : ignores the <code>oldusername</code> field and leaves the existing user account's <code>username</code> field unchanged.
;Yes : allows the existing user account's <code>username</code> to be changed by the data provided in the uploaded file's <code>username</code> field. The <code>oldusername</code> will be searched for and then updated with the data provided in the <code>username</code> column.

====Allow deletes====
If the uploaded file contains the <code>deleted</code> special field, it is possible to use the upload file to delete existing user accounts. The default setting is to '''not''' allow deletes. Keep in mind that deleting a user account will prevent that user from logging in. As a protection, site administrator user accounts cannot be deleted with this method.
;No : ignores the <code>deleted</code> special field in the uploaded file and leaves the existing user account unchanged
;Yes : allows the existing user account to be deleted when the value of the of the <code>deleted</code> field is 1.

====Allow suspending and activating of accounts====
If the uploaded file contains the <code>suspended</code> special field, it is possible to use the upload file to either suspend or make active (unsuspend) existing user accounts. The default setting is to allow suspending/activating of existing user accounts. Keep in mind that suspending an existing user account will prevent that user from logging in.
;Yes : allows the existing user account to be suspended when the value of the of the <code>suspended</code> field is 1.
;No : ignores the <code>suspended</code> special field in the uploaded file and leaves the existing user account status unchanged.

====Prevent email address duplicates====
It is possible, but '''not''' recommended to upload users with duplicate email addresses. By default, uploading users with duplicate email addresses is prevented. See MDL-38104 for some discussion. Further, since MDL-41115 added the ability for users to login with their email address it is even more important that duplicate email addresses be avoided.

To allow duplicate email addresses, go to Site administration ► Plugins ► Authentication ► Manage authentication. You can tick "Allow accounts with same email". Then on the upload users screen you will be allowed to change the "Prevent email address duplicates" setting. However, doing this is not recommended. For more info, see the [[Managing_authentication#Allow_accounts_with_same_email|Managing authentication]] docs page
;Yes : prevents user accounts from being created from the uploaded if an existing user account already has the same email address as found in the uploaded file's <code>email</code> column.
;No : allows user accounts to be created if an existing user account already has the same email address found in the uploaded file's <code>email</code> column.

====Standardise usernames====
Standardise usernames is used by default to convert the username to all lower case and to strip out illegal characters. It is possible to not standardise the usernames; however, doing so is '''not''' recommended.
;Yes : standardises usernames found in the uploaded file before updating existing or creating new user accounts so that the username contains only lowercase letters and numbers.
;No : skips standardising usernames found in the uploaded file so that the newly created or updated usernames will be exactly as they are in the uploaded file ('''not recommended''').

For those seeking a more technical explanation, the process for standardising the usernames consists of ensuring the characters are all UTF-8 (fix_utf8) encoded, converting the username to lower case, and then stripping out non-letters/non-number characters (unless ''Site administration > Security > Site policies > Allow extended characters in usernames'' is set on) with something similar to:

<code>$username = preg_replace('/[^-\.@_a-z0-9]/', '', $username);</code>

====Select for bulk user actions====
After the uploaded file has finished being processed (all new accounts have been created and existing accounts updated as specified by the previous settings), there is an option to select some of those user accounts to perform additional [[admin/user/user_bulk|bulk user actions]] such as
*Confirm user accounts created through Email-based self-registration which are not yet confirmed by the user
*Send a message (requires Messaging to be enabled)
*Delete user accounts
*Display a list of users on a page
*Download user data in text, ODS or Excel file format
*Force users to change their passwords
*Add users to a cohort

By default, no users are selected for [[admin/user/user_bulk|bulk user actions]].

;No : No users are selected for [[admin/user/user_bulk|bulk user actions]]
;New users : Only newly created users are selected for [[admin/user/user_bulk|bulk user actions]]
;Updated users : Only updated user accounts are selected for [[admin/user/user_bulk|bulk user actions]]
;All users : All users found (existing updated users and newly created user accounts) in the uploaded file are selected for [[admin/user/user_bulk|bulk user actions]]

===Default values===

You can provide default user values for some fields not included in the uploaded file. Some fields include:
*Email display
*Forum auto-subscribe
*City/town
*ID number
*Institution
*Department

==Upload user results ==
After accepting the preview settings by clicking on "Upload users", you should see the the Upload users results screen.
[[File:Upload users results 2.0.JPG|thumb|center|The results screen; everything went well!]]
This screen will show you any exceptions or changes that were made to each user in the upload process. For example if you were updating user information, the updated information will be shown. Or if a user was not added that record will be highlighted.

The screen will summarize how many users were uploaded or updated, indicate the number of weak passwords and the number of errors.

==Advanced potentials of Upload user==
===Templates===

''Note: This section needs checking and updating if necessary for Moodle 2.0. Please do so and remove this note when finished.''

The default values are processed as templates in which the following codes are allowed:

* %l - will be replaced by the lastname
* %f - will be replaced by the firstname
* %u - will be replaced by the username
* %% - will be replaced by the %

Between the percent sign (%) and any code letter (l, f or u) the following modifiers are allowed:

* (-) minus sign - the information specified by the code letter will be converted to lowercase
* (+) plus sign - the information specified by the code letter will be converted to UPPERCASE
* (~) tilde sign - the information specified by the code letter will be converted to Title Case
* a decimal number - the information specified by the code letter will be truncated to that many characters

For example, if the firstname is John and the lastname is Doe, the following values will be obtained with the specified templates:

* %l%f = DoeJohn
* %l%1f = DoeJ
* %-l%+f = doeJOHN
* %-f_%-l = john_doe
*<nowiki> http://www.example.com/~%u/</nowiki> results in <nowiki>http://www.example.com/~jdoe/</nowiki> (if the username is jdoe or %-1f%-l)

Template processing is done only on default values, and not on the values retrieved from the CSV file.

In order to create correct Moodle usernames, the username is always converted to lowercase. Moreover, if the "Allow extended characters in usernames" option in the Site policies page is off, characters different to letters, digits, dash (-) and dot (.) are removed. For example if the firstname is John Jr. and the lastname is Doe, the username %-f_%-l will produce john jr._doe when Allow extended characters in usernames is on, and johnjr.doe when off.

When the "New username duplicate handling" setting is set to Append counter, an auto-increment counter will be append to duplicate usernames produced by the template. For example, if the CSV file contains the users named John Doe, Jane Doe and Jenny Doe without explicit usernames, the default username is %-1f%-l and New username duplicate handling is set to Append counter, then the usernames produced will be jdoe, jdoe2 and jdoe3.

===Deleting accounts===

If the <code>deleted</code> field is present, users with value 1 for it will be deleted. In this case, all the fields may be omitted, except for <code>username</code>. After uploading the file, be sure to change the "Upload type" to "Update existing users only" and the "Allow deletes" option to "Yes".

:''Tip:'' A similar field is available for <code>suspended</code>. This enables a user account to be temporarily disabled rather than completely removed.

Deleting and uploading accounts could be done with a single CSV file. For example, the following file will add the user Tom Jones and delete the user reznort:

username,firstname,lastname,deleted
jonest,Tom,Jones,0
reznort,,,1

==Encoding file format==
On the initial Upload user screen, you may select the file encoding format from a pull down list. These include UTF-8 (the default), ASCII, ISO-8859-1 to ISO-8859-11 or any one of over 36 formats.

==Hints==

===Spreadsheet===

If you use a spreadsheet program such as Excel to create your .csv file, check the resulting output in a text editor before you upload it. It is possible to get trailing commas on each line from an empty field if you have added and deleted columns of information prior to saving the final file. Also check the character encoding. A csv file is a simple text file (ASCII or Unicode) that can be used to upload user accounts.

Excel translates passwords that begin with - (minus) or + (plus) as zero. Even when saving as .csv and saying "Yes" to "Keep this format, and leave out any incompatible features." Check for this before uploading, as a zero halts the upload process.

If you use a formula in Excel to create fields (for example, the concatenate function to create a user name), then remember to copy the cells with the formula and use special paste with values checked to make them into an acceptable data for a csv file.

The upload will also fail if you have trailing spaces at the end of your data fields. Often, this can not be removed with a simple Find " " and Replace with "". If information has been copied from web sources than it is possible to include non-breaking spaces which will prevent your upload from being completed correctly. To find these invisible spaces, use the Find and Replace function in Excel. In the find field, hold alt and type 0160. Leave the replace field blank.

===Country===
The country should be written as a two letter code, in capitals. For example, use BE for Belgium or NL for the Netherlands. Using "be" or "nl" or "USA" as a country code will result in a database error.
:''Tip:'' If you are having trouble working out the two-letter code for a country, you can consult the list of [http://www.iso.org/iso/country_names_and_code_elements country names and code elements] available on the ISO Website. A common error is to use UK for United Kingdom; it should be GB.

===Field size limits===
Some fields have maximum character lengths, as defined in the database fields. Typically the file will import to the preview list screen but not finish the process. Turn on debug to see the fields that are too long. The error will be "User not added - error".

The sizes of some common fields, in number of characters, are currently (3.2):

*username - 100
*password - 255
*idnumber - 255
*firstname - 100
*lastname - 100
*lastnamephonetic - 255
*firstnamephonetic - 255
*middlename - 255
*alternatename - 255
*institution - 255
*department - 255
*address - 255
*city - 120
*icq -15
*skype - 50
*yahoo - 50
*aim - 50
*msn - 50
*phone1 - 20
*phone2 - 20

===Time zones===

The entry is case sensitive so <code>Europe/London</code> will work but <code>europe/london</code> will not. Use the names from the Timezone list found in ''Site administration > Location > Default timezone'' in their proper format.

===All user fields listed here===
:All the user fields that are valid in an upload file are listed below, except for any custom fields you may have created (for which see below.)

<pre>firstname,lastname,username,email,password,auth,idnumber,institution,department,city,country,timezone,lang,mailformat,maildisplay,maildigest,htmleditor,autosubscribe,skype,msn,aim,yahoo,icq,phone1,phone2,address,url,description,descriptionformat,oldusername,deleted,suspended,alternatename,lastnamephonetic,firstnamephonetic,middlename</pre>

TIP: You can copy/paste the above as plain text and save it as a csv file to use as a template header for your upload files.

The courses are listed by number as<pre>course1,course2,course3,course4</pre> etc.

===Enroll users to Cohorts (system groups)===
You can enroll users to any Cohort (system level group) by using only the "username" and the "Cohort ID".
Here is a sample CSV file:

'''username,cohort1'''
teacher1,system-teachers
teacher2,system-teachers
teacher3,system-teachers

Make sure you set "Upload type" to "Update existing users only" (So you are not asked to add firstname, lastname and email fields too)

===Capabilities===

You may wish to create a limited role to allow some users access to this function. Create a role and assign to the user at the system/site level with the following capabilities allowed
* moodle/site:uploadusers
* moodle/role:assign
* In 'Allow role assignments' permit this new role to assign the required roles

In particular, don't forget the moodle/role:assign capability (even if these users have it in the courses they will be enrolling users in - it won't work).

== See also ==
* [http://youtu.be/PFGLZnuu_JI Adding users by using a CSV in Moodle] MoodleBites video on YouTube
*[[Flat file]] enrolment
* [[User profile fields]] for details of how to include data about custom user profile fields in the upload users file
* [[Upload courses]]

Using Moodle forum discussions:
*[http://moodle.org/mod/forum/discuss.php?d=36851 Can I auto enroll from Excel?]
*[http://moodle.org/mod/forum/discuss.php?d=97903 Uploading users to custom roles]
*[http://moodle.org/mod/forum/discuss.php?d=181259 User upload option: standardise usernames]
*[http://moodle.org/mod/forum/discuss.php?d=144569 Matriculacion con flat file csv] - discussion in Spanish

[[fr:Importer des utilisateurs]]
[[ja:ユーザのアップロード]]
[[de:Nutzerliste hochladen]]
[[es:Subir usuarios]]

Installing Moodle

2016-10-28T20:40:55Z

Howardsmiller: /* Create the (moodledata) data directory */

{{Template:Installing Moodle}}
''This page explains how to install Moodle. If you are an expert and/or in a hurry try [[Installation Quickstart]].''

If you just want to try Moodle on a standalone machine there are 'one-click' installers for Windows (see [[Complete install packages for Windows]]) and for OSX (see [[Complete Install Packages for Mac OS X]]) or [[ install on OS X]]. These are unsuitable for production servers.

== Requirements ==

Moodle is primarily developed in Linux using [[Apache]], [[PostgreSQL]]/[[MySQL]]/[[MariaDB]] and [[PHP]] (sometimes known as the LAMP platform). Typically this is also how Moodle is run, although there are other options as long as the software requirements of the [{{Release notes}} release] are met.

If you are installing Moodle in a Windows server, note that from php5.5 onwards, you will also need to have the Visual C++ Redistributable for Visual Studio 2012 installed from:
http://www.microsoft.com/en-us/download/details.aspx?id=30679 Visual C++] ( x86 or x64)

The basic requirements for Moodle are as follows:

=== Hardware ===
* Disk space: 200MB for the Moodle code, plus as much as you need to store content. 5GB is probably a realistic minimum.
* Processor: 1GHz (min), 2GHz dual core or more recommended.
* Memory: 512MB (min), 1GB or more is recommended. 8GB plus is likely on a large production server
* Consider separate servers for the web "front ends" and the database. It is much easier to "tune"

All the above requirements will vary depending on specific hardware and software combinations as well as the type of use and load; busy sites may well require additional resources. Further guidance can be found under [[Performance_recommendations|performance recommendations]]. Moodle scales easily by increasing hardware.

For very large sites, you are much better starting with a small pilot and gaining some experience and insight. A "what hardware do I need for 50,000 user?" style post in the forums is highly unlikely to get a useful answer.

=== Software ===

See the [{{Release notes}} release notes] in the dev docs for software requirements.

== Set up your server ==

Depending the use case a Moodle server may be anything from a Desktop PC (e.g. for testing and evaluating) to a rackmounted or [[Server cluster|clustered]] solution. As mentioned above there are lots of possibilities for installing the basic server software, some links and pointers are at [[Installing AMP]], [[Internet_Information_Services|IIS]], [[Nginx]].

It will help hugely, regardless of your deployment choices, if time is taken to understand how to configure the different parts of your software stack (HTTP daemon, database, PHP etc). Do not expect the standard server configuration to be optimal for Moodle. For example, the web server and database servers will almost certainly require tuning to get the best out of Moodle.

If a hosting provider is being used ensure that all Moodle [{{Release notes}}#Server_requirements requirments] (such as PHP version) are met by the hosting platform before attempting the installation. It will help to become familiar with changing settings within the hosting provider's platform (e.g. PHP file upload maximums) as the options and tools provided vary.

== Download and copy files into place ==

'''IMPORTANT: While there are now a number of places you can get the Moodle code (including host provided Moodle installers), you are strongly advised to only obtain Moodle from moodle.org. If you run into problems it will be a great deal easier to support you.'''

You have two options:
* Download your required version from http://moodle.org/downloads and unzip/unpack...
* '''OR''' Pull the code from the Git repository (recommended for developers and also makes upgrading very simple):
<pre>
$ git clone --depth=1 -b MOODLE_31_STABLE git://git.moodle.org/moodle.git
</pre>

Other options you might consider:
''--depth=1'' for shallow cloning (only) latest revision

''--single-branch'' to limit cloning to a single branch, this fetches the Moodle 3.1 Stable branch (latest weekly build). For a fuller discussion see [[Git for Administrators]].

Either of the above should result in a directory called '''moodle''', containing a number of files and folders.

You can typically place the whole folder in your web server documents directory, in which case the site will be located at '''<nowiki>http://yourwebserver.com/moodle</nowiki>''', or you can copy all the contents straight into the main web server documents directory, in which case the site will be simply '''<nowiki>http://yourwebserver.com</nowiki>'''. See the documentation for your system and/or web server if you are unsure.

:''Tip:'' If you are downloading Moodle to your local computer and then uploading it to your hosted web site, if possible upload the compressed file and decompress at the remote end (check your 'file manager'). Failing that, watch FTP progress carefully for errors or missed files.

* '''Secure the Moodle files:''' It is vital that the files are not writeable by the web server user. For example, on Unix/Linux (as root):
<pre>
# chown -R root /path/to/moodle
# chmod -R 0755 /path/to/moodle
# find /path/to/moodle -type f -exec chmod 0644 {} \;
</pre>
(files are owned by the administrator/superuser and are only writeable by them - readable by everyone else)

The third command finds all the regular files and executes the chmod command 0644 on them.

If you want to use the built-in plugin installer you need to make the directory writable by web server user. It is strongly recommended to use ACL when your server supports it, for example if your Apache server uses account www-data:

<pre>
# chmod -R +a "www-data allow read,delete,write,append,file_inherit,directory_inherit" /path/to/moodle
</pre>

The effect of the previous command is to allow the Apache user account (www-data in this case) to access and change files within the moodle site. Many people would consider this a brave move for a new site admin to implement. In a new moodle you can safely leave this out. A default Ubuntu install does not have the +a option for the chmod command anyway. The +a attribute is an ACL (Access Control List) facility which allows you to set per user access for individual files. For example, OSX has this by default.

== Create an empty database ==

Next create a new, empty database for your installation. You need to find and make a note of following information for use during the final installation stage:
* '''dbhost''' - the database server hostname. Probably ''localhost'' if the database and web server are the same machine, otherwise the name of the database server
* '''dbname''' - the database name. Whatever you called it, e.g. ''moodle''
* '''dbuser''' - the username for the database. Whatever you assigned, e.g. ''moodleuser'' - do not use the root/superuser account. Create a proper account with the minimum permissions needed.
* '''dbpass''' - the password for the above user

If your site is hosted you should find a web-based administration page for databases as part of the control panel (or ask your administrator). For everyone else or for detailed instructions, see the page for your chosen database server:
* [[PostgreSQL]]
* [[MariaDB]] (known issues - see MDL-45233)
* [[MySQL]] (known issues - see MDL-45233)
* [[MSSQL]]
* [[Oracle]] (known issues, not fully supported - see MDL-41310)

== Create the (''moodledata'') data directory ==

Moodle requires a directory to store all of its files (all your site's uploaded files, temporary data, cache, session data etc.). The web server needs to be able to write to this directory. On larger systems consider how much free space you are going to use when allocating this directory.

Due to the default way Moodle caches data you may have serious performance issues if you use relatively slow storage (e.g. NFS) for this directory. Read the [[Performance_recommendations]] carefully and consider using (e.g.) memcached for [[Caching]].

'''IMPORTANT:''' This directory must '''NOT''' be accessible directly via the web. This would be a serious security hole. Do not try to place it inside your web root or inside your Moodle program files directory. Moodle will not install. It can go anywhere else convenient.

Here is an example (Unix/Linux) of creating the directory and setting the permissions for '''anyone''' on the server to write here. This is only appropriate for Moodle servers that are not shared. Discuss this with your server administrator for better permissions that just allow the web server user to access these files.

<pre>
# mkdir /path/to/moodledata
# chmod 0777 /path/to/moodledata
</pre>

If your server supports ACL it is recommended to set following permissions, for example if your Apache server uses account www-data:
<pre>
# chmod -R +a "www-data allow read,delete,write,append,file_inherit,directory_inherit" /path/to/moodledata
</pre>
If you are planning to execute PHP scripts from the command line you should set the same permissions for the current user:
<pre>
$ sudo chmod -R +a "`whoami` allow read,delete,write,append,file_inherit,directory_inherit" /path/to/moodledata
</pre>

==== Securing moodledata in a web directory ====

If you are using a hosted site and you have no option but to place 'moodledata' in a web accessible directory. You may be able to secure it by creating an .htaccess file in the 'moodledata' directory. This does not work on all systems - see your host/administrator. Create a file called .htaccess containing only the following lines:
<pre>
order deny,allow
deny from all
</pre>

== Start Moodle install ==
It's now time to run the installer to create the database tables and configure your new site. The recommended method is to use the command line installer. If you cannot do this for any reason (e.g. on a Windows server) the web based installer is still available.

=== Command line installer ===

It's best to run the command line as your system's web user. You need to know what that is - see your system's documentation (e.g. Ubuntu/Debian is 'www-data', Centos is 'apache')

* Example of using the command-line (as root - substitute 'www-data' for your web user):
<pre>
# chown www-data /path/to/moodle
# cd /path/to/moodle/admin/cli
# sudo -u www-data /usr/bin/php install.php
# chown -R root /path/to/moodle
</pre>
The chowns allow the script to write a new config.php file. More information about the options can be found using
<pre>
# php install.php --help
</pre>

You will be asked for other settings that have not been discussed on this page - if unsure just accept the defaults. For a full discussion see [[Administration via command line]]

=== Web based installer ===

For ease of use you can install Moodle via the web. We recommend configuring your web server so that the page is not publicly accessible until the installation is complete.

To run the web installer script, just go to your Moodle's main URL using a web browser.

The installation process will take you through a number of pages. You should be asked to confirm the copyright, see the database tables being created, supply administrator account details and supply the site details. The database creation can take some time - please be patient. You should eventually end up at the Moodle front page with an invitation to create a new course.

It is very likely that you will be asked to download the new config.php file and upload it to your Moodle installation - just follow the on-screen instructions.

==Final configuration==

=== Settings within Moodle ===
There are a number of options within the Moodle Site Administration screens (accessible from the 'Site administration' tab in the 'Administration' block. Here are a few of the more important ones that you will probably want to check:
* ''Administration > Site administration > Plugins > Message Outputs > Email'': Set your smtp server and authentication if required (so your Moodle site can send emails). The support contact for your site is also set on this page.
* ''Administration > Site administration > Server > System paths'': Set the paths to du, dot and aspell binaries.
* ''Administration > Site administration > Server > HTTP'': If you are behind a firewall you may need to set your proxy credentials in the 'Web proxy' section.
* ''Administration > Site administration > Location > Update timezones'': Run this to make sure your timezone information is up to date. (more info [[Location]])
** [http://php.net/manual/en/timezones.php Set server's local timezone] inside <tt>php.ini</tt> (should probably be inside <tt>/etc/php.ini</tt> or <tt>/etc/php.d/date.ini</tt>, depending on the underline OS):
**: <code ini>[Date]
; Defines the default timezone used by the date functions
date.timezone = "YOUR LOCAL TIMEZONE"</code>

=== Remaining tasks ===

* '''Configure Cron''': Moodle's background tasks (e.g. sending out forum emails and performing course backups) are performed by a script which you can set to execute at specific times of the day. This is known as a cron script. Please refer to the [[Cron|Cron instructions]].
* '''Set up backups''': See [[Site backup]] and [[Automated course backup]].
* '''Check mail works''': [[Add a new user|Create a test user]] with a valid email address and [[message|send them a message]]. Do they receive an email copy of the message? If not, check the settings in ''Settings > Site administration > Plugins > Message outputs > Email''. Don't be tempted to skip this step (clue: email is used to recover lost passwords, including the administrator password when you forget it!)
* '''Secure your Moodle site''': Read the [[Security recommendations]].
*'''Increasing the maximum upload size''' See [[Installation FAQ]] Maximum upload file size - how to change it?

=== Installation is complete :) ===

* Create a new course: You can now access Moodle through your web browser (using the same URL as you set during the install process), log in as your admin user and creatse a new course. See [[Adding a new course|create a new course]].

=== If something goes wrong... ===

Here are some things you should try...

* Check the [[Installation FAQ]]
* Check your file permissions carefully. Can your web server read (but not write) the Moodle program files? Can your web server read and write your Moodle data directory?
* Check your database permissions. Have you set up your database user with the correct rights and permissions for your configuration (especially if the web server and database server are different machines)?
* Create your [[Configuration file]] (config.php) by hand. Copy config-dist.php (in the root of the Moodle program directory) to config.php, edit it and set your database/site options there. Installation will continue from the right place.
* Once you have a config.php (see previous tip) you can edit it to turn on debugging (in section 8). This may give you extra information to help track down a problem. If you have access, check your web server error log(s).
* Re-check your php.ini / .htaccess settings. Are they appropriate (e.g. memory_limit), did you edit the correct php.ini / .htaccess file and (if required) did you re-start the web server after making changes?
* Did you include any non-core (optional) plugins, themes or other code before starting the installation script? If so, remove it and try again (it may be broken or incompatible).
* Explain your problem in the [http://moodle.org/mod/forum/view.php?id=28 Installation problems forum]. '''PLEASE''' list your software versions; explain what you did, what happened and what error messages you saw (if any); explain what you tried. There is no such thing as 'nothing', even a blank page is something!

== Platform specific instructions ==

'''Note:''' Much of this information is provided by the community. It may not have been checked and may be out of date. Please read in conjunction with the above installation instructions.

* [[Windows installation]]
** [[Installing Moodle on SmarterASP.NET]]
* [[Unix or Linux Installation]]
* [[Mac Installation]]
* [[Amazon EC2 Cloud Services Installation]]

== See also ==
* [http://www.slideshare.net/gb2048/my-own-moodle Slideshare presentation by Gareth Barnard on installing a local installation of Moodle] and accompanying [https://drive.google.com/folderview?id=0B17B0rYH2zERU21sQnVweUZCUFk&usp=sharing help guides]
* [http://moodle.org/mod/forum/discuss.php?d=182086 New Video Tutorial- How to Install Moodle on Shared Hosting via cPanel (Not Fantastico)]
* [http://moodle.org/mod/forum/discuss.php?d=199542 Video Tutorial - Install Moodle on a Virtual Box from scratch]

[[es:Instalaci%C3%B3n_de_moodle]]
[[de:Installation von Moodle]]
[[fr:Installation de Moodle]]
[[ja:Moodleのインストール]]

Installing Moodle

2016-10-28T20:38:17Z

Howardsmiller: /* Download and copy files into place */

{{Template:Installing Moodle}}
''This page explains how to install Moodle. If you are an expert and/or in a hurry try [[Installation Quickstart]].''

If you just want to try Moodle on a standalone machine there are 'one-click' installers for Windows (see [[Complete install packages for Windows]]) and for OSX (see [[Complete Install Packages for Mac OS X]]) or [[ install on OS X]]. These are unsuitable for production servers.

== Requirements ==

Moodle is primarily developed in Linux using [[Apache]], [[PostgreSQL]]/[[MySQL]]/[[MariaDB]] and [[PHP]] (sometimes known as the LAMP platform). Typically this is also how Moodle is run, although there are other options as long as the software requirements of the [{{Release notes}} release] are met.

If you are installing Moodle in a Windows server, note that from php5.5 onwards, you will also need to have the Visual C++ Redistributable for Visual Studio 2012 installed from:
http://www.microsoft.com/en-us/download/details.aspx?id=30679 Visual C++] ( x86 or x64)

The basic requirements for Moodle are as follows:

=== Hardware ===
* Disk space: 200MB for the Moodle code, plus as much as you need to store content. 5GB is probably a realistic minimum.
* Processor: 1GHz (min), 2GHz dual core or more recommended.
* Memory: 512MB (min), 1GB or more is recommended. 8GB plus is likely on a large production server
* Consider separate servers for the web "front ends" and the database. It is much easier to "tune"

All the above requirements will vary depending on specific hardware and software combinations as well as the type of use and load; busy sites may well require additional resources. Further guidance can be found under [[Performance_recommendations|performance recommendations]]. Moodle scales easily by increasing hardware.

For very large sites, you are much better starting with a small pilot and gaining some experience and insight. A "what hardware do I need for 50,000 user?" style post in the forums is highly unlikely to get a useful answer.

=== Software ===

See the [{{Release notes}} release notes] in the dev docs for software requirements.

== Set up your server ==

Depending the use case a Moodle server may be anything from a Desktop PC (e.g. for testing and evaluating) to a rackmounted or [[Server cluster|clustered]] solution. As mentioned above there are lots of possibilities for installing the basic server software, some links and pointers are at [[Installing AMP]], [[Internet_Information_Services|IIS]], [[Nginx]].

It will help hugely, regardless of your deployment choices, if time is taken to understand how to configure the different parts of your software stack (HTTP daemon, database, PHP etc). Do not expect the standard server configuration to be optimal for Moodle. For example, the web server and database servers will almost certainly require tuning to get the best out of Moodle.

If a hosting provider is being used ensure that all Moodle [{{Release notes}}#Server_requirements requirments] (such as PHP version) are met by the hosting platform before attempting the installation. It will help to become familiar with changing settings within the hosting provider's platform (e.g. PHP file upload maximums) as the options and tools provided vary.

== Download and copy files into place ==

'''IMPORTANT: While there are now a number of places you can get the Moodle code (including host provided Moodle installers), you are strongly advised to only obtain Moodle from moodle.org. If you run into problems it will be a great deal easier to support you.'''

You have two options:
* Download your required version from http://moodle.org/downloads and unzip/unpack...
* '''OR''' Pull the code from the Git repository (recommended for developers and also makes upgrading very simple):
<pre>
$ git clone --depth=1 -b MOODLE_31_STABLE git://git.moodle.org/moodle.git
</pre>

Other options you might consider:
''--depth=1'' for shallow cloning (only) latest revision

''--single-branch'' to limit cloning to a single branch, this fetches the Moodle 3.1 Stable branch (latest weekly build). For a fuller discussion see [[Git for Administrators]].

Either of the above should result in a directory called '''moodle''', containing a number of files and folders.

You can typically place the whole folder in your web server documents directory, in which case the site will be located at '''<nowiki>http://yourwebserver.com/moodle</nowiki>''', or you can copy all the contents straight into the main web server documents directory, in which case the site will be simply '''<nowiki>http://yourwebserver.com</nowiki>'''. See the documentation for your system and/or web server if you are unsure.

:''Tip:'' If you are downloading Moodle to your local computer and then uploading it to your hosted web site, if possible upload the compressed file and decompress at the remote end (check your 'file manager'). Failing that, watch FTP progress carefully for errors or missed files.

* '''Secure the Moodle files:''' It is vital that the files are not writeable by the web server user. For example, on Unix/Linux (as root):
<pre>
# chown -R root /path/to/moodle
# chmod -R 0755 /path/to/moodle
# find /path/to/moodle -type f -exec chmod 0644 {} \;
</pre>
(files are owned by the administrator/superuser and are only writeable by them - readable by everyone else)

The third command finds all the regular files and executes the chmod command 0644 on them.

If you want to use the built-in plugin installer you need to make the directory writable by web server user. It is strongly recommended to use ACL when your server supports it, for example if your Apache server uses account www-data:

<pre>
# chmod -R +a "www-data allow read,delete,write,append,file_inherit,directory_inherit" /path/to/moodle
</pre>

The effect of the previous command is to allow the Apache user account (www-data in this case) to access and change files within the moodle site. Many people would consider this a brave move for a new site admin to implement. In a new moodle you can safely leave this out. A default Ubuntu install does not have the +a option for the chmod command anyway. The +a attribute is an ACL (Access Control List) facility which allows you to set per user access for individual files. For example, OSX has this by default.

== Create an empty database ==

Next create a new, empty database for your installation. You need to find and make a note of following information for use during the final installation stage:
* '''dbhost''' - the database server hostname. Probably ''localhost'' if the database and web server are the same machine, otherwise the name of the database server
* '''dbname''' - the database name. Whatever you called it, e.g. ''moodle''
* '''dbuser''' - the username for the database. Whatever you assigned, e.g. ''moodleuser'' - do not use the root/superuser account. Create a proper account with the minimum permissions needed.
* '''dbpass''' - the password for the above user

If your site is hosted you should find a web-based administration page for databases as part of the control panel (or ask your administrator). For everyone else or for detailed instructions, see the page for your chosen database server:
* [[PostgreSQL]]
* [[MariaDB]] (known issues - see MDL-45233)
* [[MySQL]] (known issues - see MDL-45233)
* [[MSSQL]]
* [[Oracle]] (known issues, not fully supported - see MDL-41310)

== Create the (''moodledata'') data directory ==

Moodle requires a directory to store all of its files (all your site's uploaded files, temporary data, cache, session data etc.). The web server needs to be able to write to this directory. On larger systems consider how much free space you are going to use when allocating this directory.

Due to the way Moodle caches data you may have performance issues if you use relatively slow storage (e.g. NFS) for this directory. Read the [[Performance_recommendations]] carefully and consider using (e.g.) memcached for [[Caching]].

'''IMPORTANT:''' This directory must '''NOT''' be accessible directly via the web. This would be a serious security hole. Do not try to place it inside your web root or inside your Moodle program files directory. Moodle will not install. It can go anywhere else convenient.

Here is an example (Unix/Linux) of creating the directory and setting the permissions for '''anyone''' on the server to write here. This is only appropriate for Moodle servers that are not shared. Discuss this with your server administrator for better permissions that just allow the web server user to access these files.

<pre>
# mkdir /path/to/moodledata
# chmod 0777 /path/to/moodledata
</pre>

If your server supports ACL it is recommended to set following permissions, for example if your Apache server uses account www-data:
<pre>
# chmod -R +a "www-data allow read,delete,write,append,file_inherit,directory_inherit" /path/to/moodledata
</pre>
If you are planning to execute PHP scripts from the command line you should set the same permissions for the current user:
<pre>
$ sudo chmod -R +a "`whoami` allow read,delete,write,append,file_inherit,directory_inherit" /path/to/moodledata
</pre>

==== Securing moodledata in a web directory ====

If you are using a hosted site and you have no option but to place 'moodledata' in a web accessible directory. You may be able to secure it by creating an .htaccess file in the 'moodledata' directory. This does not work on all systems - see your host/administrator. Create a file called .htaccess containing only the following lines:
<pre>
order deny,allow
deny from all
</pre>

== Start Moodle install ==
It's now time to run the installer to create the database tables and configure your new site. The recommended method is to use the command line installer. If you cannot do this for any reason (e.g. on a Windows server) the web based installer is still available.

=== Command line installer ===

It's best to run the command line as your system's web user. You need to know what that is - see your system's documentation (e.g. Ubuntu/Debian is 'www-data', Centos is 'apache')

* Example of using the command-line (as root - substitute 'www-data' for your web user):
<pre>
# chown www-data /path/to/moodle
# cd /path/to/moodle/admin/cli
# sudo -u www-data /usr/bin/php install.php
# chown -R root /path/to/moodle
</pre>
The chowns allow the script to write a new config.php file. More information about the options can be found using
<pre>
# php install.php --help
</pre>

You will be asked for other settings that have not been discussed on this page - if unsure just accept the defaults. For a full discussion see [[Administration via command line]]

=== Web based installer ===

For ease of use you can install Moodle via the web. We recommend configuring your web server so that the page is not publicly accessible until the installation is complete.

To run the web installer script, just go to your Moodle's main URL using a web browser.

The installation process will take you through a number of pages. You should be asked to confirm the copyright, see the database tables being created, supply administrator account details and supply the site details. The database creation can take some time - please be patient. You should eventually end up at the Moodle front page with an invitation to create a new course.

It is very likely that you will be asked to download the new config.php file and upload it to your Moodle installation - just follow the on-screen instructions.

==Final configuration==

=== Settings within Moodle ===
There are a number of options within the Moodle Site Administration screens (accessible from the 'Site administration' tab in the 'Administration' block. Here are a few of the more important ones that you will probably want to check:
* ''Administration > Site administration > Plugins > Message Outputs > Email'': Set your smtp server and authentication if required (so your Moodle site can send emails). The support contact for your site is also set on this page.
* ''Administration > Site administration > Server > System paths'': Set the paths to du, dot and aspell binaries.
* ''Administration > Site administration > Server > HTTP'': If you are behind a firewall you may need to set your proxy credentials in the 'Web proxy' section.
* ''Administration > Site administration > Location > Update timezones'': Run this to make sure your timezone information is up to date. (more info [[Location]])
** [http://php.net/manual/en/timezones.php Set server's local timezone] inside <tt>php.ini</tt> (should probably be inside <tt>/etc/php.ini</tt> or <tt>/etc/php.d/date.ini</tt>, depending on the underline OS):
**: <code ini>[Date]
; Defines the default timezone used by the date functions
date.timezone = "YOUR LOCAL TIMEZONE"</code>

=== Remaining tasks ===

* '''Configure Cron''': Moodle's background tasks (e.g. sending out forum emails and performing course backups) are performed by a script which you can set to execute at specific times of the day. This is known as a cron script. Please refer to the [[Cron|Cron instructions]].
* '''Set up backups''': See [[Site backup]] and [[Automated course backup]].
* '''Check mail works''': [[Add a new user|Create a test user]] with a valid email address and [[message|send them a message]]. Do they receive an email copy of the message? If not, check the settings in ''Settings > Site administration > Plugins > Message outputs > Email''. Don't be tempted to skip this step (clue: email is used to recover lost passwords, including the administrator password when you forget it!)
* '''Secure your Moodle site''': Read the [[Security recommendations]].
*'''Increasing the maximum upload size''' See [[Installation FAQ]] Maximum upload file size - how to change it?

=== Installation is complete :) ===

* Create a new course: You can now access Moodle through your web browser (using the same URL as you set during the install process), log in as your admin user and creatse a new course. See [[Adding a new course|create a new course]].

=== If something goes wrong... ===

Here are some things you should try...

* Check the [[Installation FAQ]]
* Check your file permissions carefully. Can your web server read (but not write) the Moodle program files? Can your web server read and write your Moodle data directory?
* Check your database permissions. Have you set up your database user with the correct rights and permissions for your configuration (especially if the web server and database server are different machines)?
* Create your [[Configuration file]] (config.php) by hand. Copy config-dist.php (in the root of the Moodle program directory) to config.php, edit it and set your database/site options there. Installation will continue from the right place.
* Once you have a config.php (see previous tip) you can edit it to turn on debugging (in section 8). This may give you extra information to help track down a problem. If you have access, check your web server error log(s).
* Re-check your php.ini / .htaccess settings. Are they appropriate (e.g. memory_limit), did you edit the correct php.ini / .htaccess file and (if required) did you re-start the web server after making changes?
* Did you include any non-core (optional) plugins, themes or other code before starting the installation script? If so, remove it and try again (it may be broken or incompatible).
* Explain your problem in the [http://moodle.org/mod/forum/view.php?id=28 Installation problems forum]. '''PLEASE''' list your software versions; explain what you did, what happened and what error messages you saw (if any); explain what you tried. There is no such thing as 'nothing', even a blank page is something!

== Platform specific instructions ==

'''Note:''' Much of this information is provided by the community. It may not have been checked and may be out of date. Please read in conjunction with the above installation instructions.

* [[Windows installation]]
** [[Installing Moodle on SmarterASP.NET]]
* [[Unix or Linux Installation]]
* [[Mac Installation]]
* [[Amazon EC2 Cloud Services Installation]]

== See also ==
* [http://www.slideshare.net/gb2048/my-own-moodle Slideshare presentation by Gareth Barnard on installing a local installation of Moodle] and accompanying [https://drive.google.com/folderview?id=0B17B0rYH2zERU21sQnVweUZCUFk&usp=sharing help guides]
* [http://moodle.org/mod/forum/discuss.php?d=182086 New Video Tutorial- How to Install Moodle on Shared Hosting via cPanel (Not Fantastico)]
* [http://moodle.org/mod/forum/discuss.php?d=199542 Video Tutorial - Install Moodle on a Virtual Box from scratch]

[[es:Instalaci%C3%B3n_de_moodle]]
[[de:Installation von Moodle]]
[[fr:Installation de Moodle]]
[[ja:Moodleのインストール]]

Installing Moodle

2016-10-28T20:36:51Z

Howardsmiller: /* Download and copy files into place */

{{Template:Installing Moodle}}
''This page explains how to install Moodle. If you are an expert and/or in a hurry try [[Installation Quickstart]].''

If you just want to try Moodle on a standalone machine there are 'one-click' installers for Windows (see [[Complete install packages for Windows]]) and for OSX (see [[Complete Install Packages for Mac OS X]]) or [[ install on OS X]]. These are unsuitable for production servers.

== Requirements ==

Moodle is primarily developed in Linux using [[Apache]], [[PostgreSQL]]/[[MySQL]]/[[MariaDB]] and [[PHP]] (sometimes known as the LAMP platform). Typically this is also how Moodle is run, although there are other options as long as the software requirements of the [{{Release notes}} release] are met.

If you are installing Moodle in a Windows server, note that from php5.5 onwards, you will also need to have the Visual C++ Redistributable for Visual Studio 2012 installed from:
http://www.microsoft.com/en-us/download/details.aspx?id=30679 Visual C++] ( x86 or x64)

The basic requirements for Moodle are as follows:

=== Hardware ===
* Disk space: 200MB for the Moodle code, plus as much as you need to store content. 5GB is probably a realistic minimum.
* Processor: 1GHz (min), 2GHz dual core or more recommended.
* Memory: 512MB (min), 1GB or more is recommended. 8GB plus is likely on a large production server
* Consider separate servers for the web "front ends" and the database. It is much easier to "tune"

All the above requirements will vary depending on specific hardware and software combinations as well as the type of use and load; busy sites may well require additional resources. Further guidance can be found under [[Performance_recommendations|performance recommendations]]. Moodle scales easily by increasing hardware.

For very large sites, you are much better starting with a small pilot and gaining some experience and insight. A "what hardware do I need for 50,000 user?" style post in the forums is highly unlikely to get a useful answer.

=== Software ===

See the [{{Release notes}} release notes] in the dev docs for software requirements.

== Set up your server ==

Depending the use case a Moodle server may be anything from a Desktop PC (e.g. for testing and evaluating) to a rackmounted or [[Server cluster|clustered]] solution. As mentioned above there are lots of possibilities for installing the basic server software, some links and pointers are at [[Installing AMP]], [[Internet_Information_Services|IIS]], [[Nginx]].

It will help hugely, regardless of your deployment choices, if time is taken to understand how to configure the different parts of your software stack (HTTP daemon, database, PHP etc). Do not expect the standard server configuration to be optimal for Moodle. For example, the web server and database servers will almost certainly require tuning to get the best out of Moodle.

If a hosting provider is being used ensure that all Moodle [{{Release notes}}#Server_requirements requirments] (such as PHP version) are met by the hosting platform before attempting the installation. It will help to become familiar with changing settings within the hosting provider's platform (e.g. PHP file upload maximums) as the options and tools provided vary.

== Download and copy files into place ==

'''IMPORTANT: While there are now a number of places you can get the Moodle code (including host provided Moodle installers), you are strongly advised to only obtain Moodle from moodle.org. If you run into problems it will be a great deal easier to support you.'''

You have two options:
* Download your required version from http://moodle.org/downloads and unzip/unpack...
* '''OR''' Pull the code from the Git repository (recommended for developers and also makes upgrading very simple):
<pre>
$ git clone --depth=1 -b MOODLE_31_STABLE git://git.moodle.org/moodle.git
</pre>

Other options you might consider:
''--depth=1'' for shallow cloning (only) latest revision

''--single-branch'' to limit cloning to a single branch, this fetches the Moodle 3.1 Stable branch (latest weekly build). For a fuller discussion see [[Git for Administrators]].

Either of the above should result in a directory called '''moodle''', containing a number of files and folders.

You can either place the whole folder in your web server documents directory, in which case the site will be located at '''<nowiki>http://yourwebserver.com/moodle</nowiki>''', or you can copy all the contents straight into the main web server documents directory, in which case the site will be simply '''<nowiki>http://yourwebserver.com</nowiki>'''. See the documentation for your system and/or web server if you are unsure.

:''Tip:'' If you are downloading Moodle to your local computer and then uploading it to your hosted web site, if possible upload the compressed file and decompress at the remote end (check your 'file manager'). Failing that, watch FTP progress carefully for errors or missed files.

* '''Secure the Moodle files:''' It is vital that the files are not writeable by the web server user. For example, on Unix/Linux (as root):
<pre>
# chown -R root /path/to/moodle
# chmod -R 0755 /path/to/moodle
# find /path/to/moodle -type f -exec chmod 0644 {} \;
</pre>
(files are owned by the administrator/superuser and are only writeable by them - readable by everyone else)

The third command finds all the regular files and executes the chmod command 0644 on them.

If you want to use the built-in plugin installer you need to make the directory writable by web server user. It is strongly recommended to use ACL when your server supports it, for example if your Apache server uses account www-data:

<pre>
# chmod -R +a "www-data allow read,delete,write,append,file_inherit,directory_inherit" /path/to/moodle
</pre>

The effect of the previous command is to allow the Apache user account (www-data in this case) to access and change files within the moodle site. Many people would consider this a brave move for a new site admin to implement. In a new moodle you can safely leave this out. A default Ubuntu install does not have the +a option for the chmod command anyway. The +a attribute is an ACL (Access Control List) facility which allows you to set per user access for individual files. For example, OSX has this by default.

== Create an empty database ==

Next create a new, empty database for your installation. You need to find and make a note of following information for use during the final installation stage:
* '''dbhost''' - the database server hostname. Probably ''localhost'' if the database and web server are the same machine, otherwise the name of the database server
* '''dbname''' - the database name. Whatever you called it, e.g. ''moodle''
* '''dbuser''' - the username for the database. Whatever you assigned, e.g. ''moodleuser'' - do not use the root/superuser account. Create a proper account with the minimum permissions needed.
* '''dbpass''' - the password for the above user

If your site is hosted you should find a web-based administration page for databases as part of the control panel (or ask your administrator). For everyone else or for detailed instructions, see the page for your chosen database server:
* [[PostgreSQL]]
* [[MariaDB]] (known issues - see MDL-45233)
* [[MySQL]] (known issues - see MDL-45233)
* [[MSSQL]]
* [[Oracle]] (known issues, not fully supported - see MDL-41310)

== Create the (''moodledata'') data directory ==

Moodle requires a directory to store all of its files (all your site's uploaded files, temporary data, cache, session data etc.). The web server needs to be able to write to this directory. On larger systems consider how much free space you are going to use when allocating this directory.

Due to the way Moodle caches data you may have performance issues if you use relatively slow storage (e.g. NFS) for this directory. Read the [[Performance_recommendations]] carefully and consider using (e.g.) memcached for [[Caching]].

'''IMPORTANT:''' This directory must '''NOT''' be accessible directly via the web. This would be a serious security hole. Do not try to place it inside your web root or inside your Moodle program files directory. Moodle will not install. It can go anywhere else convenient.

Here is an example (Unix/Linux) of creating the directory and setting the permissions for '''anyone''' on the server to write here. This is only appropriate for Moodle servers that are not shared. Discuss this with your server administrator for better permissions that just allow the web server user to access these files.

<pre>
# mkdir /path/to/moodledata
# chmod 0777 /path/to/moodledata
</pre>

If your server supports ACL it is recommended to set following permissions, for example if your Apache server uses account www-data:
<pre>
# chmod -R +a "www-data allow read,delete,write,append,file_inherit,directory_inherit" /path/to/moodledata
</pre>
If you are planning to execute PHP scripts from the command line you should set the same permissions for the current user:
<pre>
$ sudo chmod -R +a "`whoami` allow read,delete,write,append,file_inherit,directory_inherit" /path/to/moodledata
</pre>

==== Securing moodledata in a web directory ====

If you are using a hosted site and you have no option but to place 'moodledata' in a web accessible directory. You may be able to secure it by creating an .htaccess file in the 'moodledata' directory. This does not work on all systems - see your host/administrator. Create a file called .htaccess containing only the following lines:
<pre>
order deny,allow
deny from all
</pre>

== Start Moodle install ==
It's now time to run the installer to create the database tables and configure your new site. The recommended method is to use the command line installer. If you cannot do this for any reason (e.g. on a Windows server) the web based installer is still available.

=== Command line installer ===

It's best to run the command line as your system's web user. You need to know what that is - see your system's documentation (e.g. Ubuntu/Debian is 'www-data', Centos is 'apache')

* Example of using the command-line (as root - substitute 'www-data' for your web user):
<pre>
# chown www-data /path/to/moodle
# cd /path/to/moodle/admin/cli
# sudo -u www-data /usr/bin/php install.php
# chown -R root /path/to/moodle
</pre>
The chowns allow the script to write a new config.php file. More information about the options can be found using
<pre>
# php install.php --help
</pre>

You will be asked for other settings that have not been discussed on this page - if unsure just accept the defaults. For a full discussion see [[Administration via command line]]

=== Web based installer ===

For ease of use you can install Moodle via the web. We recommend configuring your web server so that the page is not publicly accessible until the installation is complete.

To run the web installer script, just go to your Moodle's main URL using a web browser.

The installation process will take you through a number of pages. You should be asked to confirm the copyright, see the database tables being created, supply administrator account details and supply the site details. The database creation can take some time - please be patient. You should eventually end up at the Moodle front page with an invitation to create a new course.

It is very likely that you will be asked to download the new config.php file and upload it to your Moodle installation - just follow the on-screen instructions.

==Final configuration==

=== Settings within Moodle ===
There are a number of options within the Moodle Site Administration screens (accessible from the 'Site administration' tab in the 'Administration' block. Here are a few of the more important ones that you will probably want to check:
* ''Administration > Site administration > Plugins > Message Outputs > Email'': Set your smtp server and authentication if required (so your Moodle site can send emails). The support contact for your site is also set on this page.
* ''Administration > Site administration > Server > System paths'': Set the paths to du, dot and aspell binaries.
* ''Administration > Site administration > Server > HTTP'': If you are behind a firewall you may need to set your proxy credentials in the 'Web proxy' section.
* ''Administration > Site administration > Location > Update timezones'': Run this to make sure your timezone information is up to date. (more info [[Location]])
** [http://php.net/manual/en/timezones.php Set server's local timezone] inside <tt>php.ini</tt> (should probably be inside <tt>/etc/php.ini</tt> or <tt>/etc/php.d/date.ini</tt>, depending on the underline OS):
**: <code ini>[Date]
; Defines the default timezone used by the date functions
date.timezone = "YOUR LOCAL TIMEZONE"</code>

=== Remaining tasks ===

* '''Configure Cron''': Moodle's background tasks (e.g. sending out forum emails and performing course backups) are performed by a script which you can set to execute at specific times of the day. This is known as a cron script. Please refer to the [[Cron|Cron instructions]].
* '''Set up backups''': See [[Site backup]] and [[Automated course backup]].
* '''Check mail works''': [[Add a new user|Create a test user]] with a valid email address and [[message|send them a message]]. Do they receive an email copy of the message? If not, check the settings in ''Settings > Site administration > Plugins > Message outputs > Email''. Don't be tempted to skip this step (clue: email is used to recover lost passwords, including the administrator password when you forget it!)
* '''Secure your Moodle site''': Read the [[Security recommendations]].
*'''Increasing the maximum upload size''' See [[Installation FAQ]] Maximum upload file size - how to change it?

=== Installation is complete :) ===

* Create a new course: You can now access Moodle through your web browser (using the same URL as you set during the install process), log in as your admin user and creatse a new course. See [[Adding a new course|create a new course]].

=== If something goes wrong... ===

Here are some things you should try...

* Check the [[Installation FAQ]]
* Check your file permissions carefully. Can your web server read (but not write) the Moodle program files? Can your web server read and write your Moodle data directory?
* Check your database permissions. Have you set up your database user with the correct rights and permissions for your configuration (especially if the web server and database server are different machines)?
* Create your [[Configuration file]] (config.php) by hand. Copy config-dist.php (in the root of the Moodle program directory) to config.php, edit it and set your database/site options there. Installation will continue from the right place.
* Once you have a config.php (see previous tip) you can edit it to turn on debugging (in section 8). This may give you extra information to help track down a problem. If you have access, check your web server error log(s).
* Re-check your php.ini / .htaccess settings. Are they appropriate (e.g. memory_limit), did you edit the correct php.ini / .htaccess file and (if required) did you re-start the web server after making changes?
* Did you include any non-core (optional) plugins, themes or other code before starting the installation script? If so, remove it and try again (it may be broken or incompatible).
* Explain your problem in the [http://moodle.org/mod/forum/view.php?id=28 Installation problems forum]. '''PLEASE''' list your software versions; explain what you did, what happened and what error messages you saw (if any); explain what you tried. There is no such thing as 'nothing', even a blank page is something!

== Platform specific instructions ==

'''Note:''' Much of this information is provided by the community. It may not have been checked and may be out of date. Please read in conjunction with the above installation instructions.

* [[Windows installation]]
** [[Installing Moodle on SmarterASP.NET]]
* [[Unix or Linux Installation]]
* [[Mac Installation]]
* [[Amazon EC2 Cloud Services Installation]]

== See also ==
* [http://www.slideshare.net/gb2048/my-own-moodle Slideshare presentation by Gareth Barnard on installing a local installation of Moodle] and accompanying [https://drive.google.com/folderview?id=0B17B0rYH2zERU21sQnVweUZCUFk&usp=sharing help guides]
* [http://moodle.org/mod/forum/discuss.php?d=182086 New Video Tutorial- How to Install Moodle on Shared Hosting via cPanel (Not Fantastico)]
* [http://moodle.org/mod/forum/discuss.php?d=199542 Video Tutorial - Install Moodle on a Virtual Box from scratch]

[[es:Instalaci%C3%B3n_de_moodle]]
[[de:Installation von Moodle]]
[[fr:Installation de Moodle]]
[[ja:Moodleのインストール]]

Installing Moodle

2016-10-28T20:35:56Z

Howardsmiller: /* Set up your server */

{{Template:Installing Moodle}}
''This page explains how to install Moodle. If you are an expert and/or in a hurry try [[Installation Quickstart]].''

If you just want to try Moodle on a standalone machine there are 'one-click' installers for Windows (see [[Complete install packages for Windows]]) and for OSX (see [[Complete Install Packages for Mac OS X]]) or [[ install on OS X]]. These are unsuitable for production servers.

== Requirements ==

Moodle is primarily developed in Linux using [[Apache]], [[PostgreSQL]]/[[MySQL]]/[[MariaDB]] and [[PHP]] (sometimes known as the LAMP platform). Typically this is also how Moodle is run, although there are other options as long as the software requirements of the [{{Release notes}} release] are met.

If you are installing Moodle in a Windows server, note that from php5.5 onwards, you will also need to have the Visual C++ Redistributable for Visual Studio 2012 installed from:
http://www.microsoft.com/en-us/download/details.aspx?id=30679 Visual C++] ( x86 or x64)

The basic requirements for Moodle are as follows:

=== Hardware ===
* Disk space: 200MB for the Moodle code, plus as much as you need to store content. 5GB is probably a realistic minimum.
* Processor: 1GHz (min), 2GHz dual core or more recommended.
* Memory: 512MB (min), 1GB or more is recommended. 8GB plus is likely on a large production server
* Consider separate servers for the web "front ends" and the database. It is much easier to "tune"

All the above requirements will vary depending on specific hardware and software combinations as well as the type of use and load; busy sites may well require additional resources. Further guidance can be found under [[Performance_recommendations|performance recommendations]]. Moodle scales easily by increasing hardware.

For very large sites, you are much better starting with a small pilot and gaining some experience and insight. A "what hardware do I need for 50,000 user?" style post in the forums is highly unlikely to get a useful answer.

=== Software ===

See the [{{Release notes}} release notes] in the dev docs for software requirements.

== Set up your server ==

Depending the use case a Moodle server may be anything from a Desktop PC (e.g. for testing and evaluating) to a rackmounted or [[Server cluster|clustered]] solution. As mentioned above there are lots of possibilities for installing the basic server software, some links and pointers are at [[Installing AMP]], [[Internet_Information_Services|IIS]], [[Nginx]].

It will help hugely, regardless of your deployment choices, if time is taken to understand how to configure the different parts of your software stack (HTTP daemon, database, PHP etc). Do not expect the standard server configuration to be optimal for Moodle. For example, the web server and database servers will almost certainly require tuning to get the best out of Moodle.

If a hosting provider is being used ensure that all Moodle [{{Release notes}}#Server_requirements requirments] (such as PHP version) are met by the hosting platform before attempting the installation. It will help to become familiar with changing settings within the hosting provider's platform (e.g. PHP file upload maximums) as the options and tools provided vary.

== Download and copy files into place ==

'''IMPORTANT: While there are now a number of places you can get the Moodle code, you are strongly advised to obtain Moodle from moodle.org. If you run into problems it will be a great deal easier to support you.'''

You have two options:
* Download your required version from http://moodle.org/downloads and unzip/unpack...
* '''OR''' Pull the code from the Git repository (recommended for developers and also makes upgrading very simple):
<pre>
$ git clone --depth=1 -b MOODLE_31_STABLE git://git.moodle.org/moodle.git
</pre>

Other options you might consider:
''--depth=1'' for shallow cloning (only) latest revision

''--single-branch'' to limit cloning to a single branch, this fetches the Moodle 3.1 Stable branch (latest weekly build). For a fuller discussion see [[Git for Administrators]].

Either of the above should result in a directory called '''moodle''', containing a number of files and folders.

You can either place the whole folder in your web server documents directory, in which case the site will be located at '''<nowiki>http://yourwebserver.com/moodle</nowiki>''', or you can copy all the contents straight into the main web server documents directory, in which case the site will be simply '''<nowiki>http://yourwebserver.com</nowiki>'''. See the documentation for your system and/or web server if you are unsure.

:''Tip:'' If you are downloading Moodle to your local computer and then uploading it to your hosted web site, if possible upload the compressed file and decompress at the remote end (check your 'file manager'). Failing that, watch FTP progress carefully for errors or missed files.

* '''Secure the Moodle files:''' It is vital that the files are not writeable by the web server user. For example, on Unix/Linux (as root):
<pre>
# chown -R root /path/to/moodle
# chmod -R 0755 /path/to/moodle
# find /path/to/moodle -type f -exec chmod 0644 {} \;
</pre>
(files are owned by the administrator/superuser and are only writeable by them - readable by everyone else)

The third command finds all the regular files and executes the chmod command 0644 on them.

If you want to use the built-in plugin installer you need to make the directory writable by web server user. It is strongly recommended to use ACL when your server supports it, for example if your Apache server uses account www-data:

<pre>
# chmod -R +a "www-data allow read,delete,write,append,file_inherit,directory_inherit" /path/to/moodle
</pre>

The effect of the previous command is to allow the Apache user account (www-data in this case) to access and change files within the moodle site. Many people would consider this a brave move for a new site admin to implement. In a new moodle you can safely leave this out. A default Ubuntu install does not have the +a option for the chmod command anyway. The +a attribute is an ACL (Access Control List) facility which allows you to set per user access for individual files. For example, OSX has this by default.

== Create an empty database ==

Next create a new, empty database for your installation. You need to find and make a note of following information for use during the final installation stage:
* '''dbhost''' - the database server hostname. Probably ''localhost'' if the database and web server are the same machine, otherwise the name of the database server
* '''dbname''' - the database name. Whatever you called it, e.g. ''moodle''
* '''dbuser''' - the username for the database. Whatever you assigned, e.g. ''moodleuser'' - do not use the root/superuser account. Create a proper account with the minimum permissions needed.
* '''dbpass''' - the password for the above user

If your site is hosted you should find a web-based administration page for databases as part of the control panel (or ask your administrator). For everyone else or for detailed instructions, see the page for your chosen database server:
* [[PostgreSQL]]
* [[MariaDB]] (known issues - see MDL-45233)
* [[MySQL]] (known issues - see MDL-45233)
* [[MSSQL]]
* [[Oracle]] (known issues, not fully supported - see MDL-41310)

== Create the (''moodledata'') data directory ==

Moodle requires a directory to store all of its files (all your site's uploaded files, temporary data, cache, session data etc.). The web server needs to be able to write to this directory. On larger systems consider how much free space you are going to use when allocating this directory.

Due to the way Moodle caches data you may have performance issues if you use relatively slow storage (e.g. NFS) for this directory. Read the [[Performance_recommendations]] carefully and consider using (e.g.) memcached for [[Caching]].

'''IMPORTANT:''' This directory must '''NOT''' be accessible directly via the web. This would be a serious security hole. Do not try to place it inside your web root or inside your Moodle program files directory. Moodle will not install. It can go anywhere else convenient.

Here is an example (Unix/Linux) of creating the directory and setting the permissions for '''anyone''' on the server to write here. This is only appropriate for Moodle servers that are not shared. Discuss this with your server administrator for better permissions that just allow the web server user to access these files.

<pre>
# mkdir /path/to/moodledata
# chmod 0777 /path/to/moodledata
</pre>

If your server supports ACL it is recommended to set following permissions, for example if your Apache server uses account www-data:
<pre>
# chmod -R +a "www-data allow read,delete,write,append,file_inherit,directory_inherit" /path/to/moodledata
</pre>
If you are planning to execute PHP scripts from the command line you should set the same permissions for the current user:
<pre>
$ sudo chmod -R +a "`whoami` allow read,delete,write,append,file_inherit,directory_inherit" /path/to/moodledata
</pre>

==== Securing moodledata in a web directory ====

If you are using a hosted site and you have no option but to place 'moodledata' in a web accessible directory. You may be able to secure it by creating an .htaccess file in the 'moodledata' directory. This does not work on all systems - see your host/administrator. Create a file called .htaccess containing only the following lines:
<pre>
order deny,allow
deny from all
</pre>

== Start Moodle install ==
It's now time to run the installer to create the database tables and configure your new site. The recommended method is to use the command line installer. If you cannot do this for any reason (e.g. on a Windows server) the web based installer is still available.

=== Command line installer ===

It's best to run the command line as your system's web user. You need to know what that is - see your system's documentation (e.g. Ubuntu/Debian is 'www-data', Centos is 'apache')

* Example of using the command-line (as root - substitute 'www-data' for your web user):
<pre>
# chown www-data /path/to/moodle
# cd /path/to/moodle/admin/cli
# sudo -u www-data /usr/bin/php install.php
# chown -R root /path/to/moodle
</pre>
The chowns allow the script to write a new config.php file. More information about the options can be found using
<pre>
# php install.php --help
</pre>

You will be asked for other settings that have not been discussed on this page - if unsure just accept the defaults. For a full discussion see [[Administration via command line]]

=== Web based installer ===

For ease of use you can install Moodle via the web. We recommend configuring your web server so that the page is not publicly accessible until the installation is complete.

To run the web installer script, just go to your Moodle's main URL using a web browser.

The installation process will take you through a number of pages. You should be asked to confirm the copyright, see the database tables being created, supply administrator account details and supply the site details. The database creation can take some time - please be patient. You should eventually end up at the Moodle front page with an invitation to create a new course.

It is very likely that you will be asked to download the new config.php file and upload it to your Moodle installation - just follow the on-screen instructions.

==Final configuration==

=== Settings within Moodle ===
There are a number of options within the Moodle Site Administration screens (accessible from the 'Site administration' tab in the 'Administration' block. Here are a few of the more important ones that you will probably want to check:
* ''Administration > Site administration > Plugins > Message Outputs > Email'': Set your smtp server and authentication if required (so your Moodle site can send emails). The support contact for your site is also set on this page.
* ''Administration > Site administration > Server > System paths'': Set the paths to du, dot and aspell binaries.
* ''Administration > Site administration > Server > HTTP'': If you are behind a firewall you may need to set your proxy credentials in the 'Web proxy' section.
* ''Administration > Site administration > Location > Update timezones'': Run this to make sure your timezone information is up to date. (more info [[Location]])
** [http://php.net/manual/en/timezones.php Set server's local timezone] inside <tt>php.ini</tt> (should probably be inside <tt>/etc/php.ini</tt> or <tt>/etc/php.d/date.ini</tt>, depending on the underline OS):
**: <code ini>[Date]
; Defines the default timezone used by the date functions
date.timezone = "YOUR LOCAL TIMEZONE"</code>

=== Remaining tasks ===

* '''Configure Cron''': Moodle's background tasks (e.g. sending out forum emails and performing course backups) are performed by a script which you can set to execute at specific times of the day. This is known as a cron script. Please refer to the [[Cron|Cron instructions]].
* '''Set up backups''': See [[Site backup]] and [[Automated course backup]].
* '''Check mail works''': [[Add a new user|Create a test user]] with a valid email address and [[message|send them a message]]. Do they receive an email copy of the message? If not, check the settings in ''Settings > Site administration > Plugins > Message outputs > Email''. Don't be tempted to skip this step (clue: email is used to recover lost passwords, including the administrator password when you forget it!)
* '''Secure your Moodle site''': Read the [[Security recommendations]].
*'''Increasing the maximum upload size''' See [[Installation FAQ]] Maximum upload file size - how to change it?

=== Installation is complete :) ===

* Create a new course: You can now access Moodle through your web browser (using the same URL as you set during the install process), log in as your admin user and creatse a new course. See [[Adding a new course|create a new course]].

=== If something goes wrong... ===

Here are some things you should try...

* Check the [[Installation FAQ]]
* Check your file permissions carefully. Can your web server read (but not write) the Moodle program files? Can your web server read and write your Moodle data directory?
* Check your database permissions. Have you set up your database user with the correct rights and permissions for your configuration (especially if the web server and database server are different machines)?
* Create your [[Configuration file]] (config.php) by hand. Copy config-dist.php (in the root of the Moodle program directory) to config.php, edit it and set your database/site options there. Installation will continue from the right place.
* Once you have a config.php (see previous tip) you can edit it to turn on debugging (in section 8). This may give you extra information to help track down a problem. If you have access, check your web server error log(s).
* Re-check your php.ini / .htaccess settings. Are they appropriate (e.g. memory_limit), did you edit the correct php.ini / .htaccess file and (if required) did you re-start the web server after making changes?
* Did you include any non-core (optional) plugins, themes or other code before starting the installation script? If so, remove it and try again (it may be broken or incompatible).
* Explain your problem in the [http://moodle.org/mod/forum/view.php?id=28 Installation problems forum]. '''PLEASE''' list your software versions; explain what you did, what happened and what error messages you saw (if any); explain what you tried. There is no such thing as 'nothing', even a blank page is something!

== Platform specific instructions ==

'''Note:''' Much of this information is provided by the community. It may not have been checked and may be out of date. Please read in conjunction with the above installation instructions.

* [[Windows installation]]
** [[Installing Moodle on SmarterASP.NET]]
* [[Unix or Linux Installation]]
* [[Mac Installation]]
* [[Amazon EC2 Cloud Services Installation]]

== See also ==
* [http://www.slideshare.net/gb2048/my-own-moodle Slideshare presentation by Gareth Barnard on installing a local installation of Moodle] and accompanying [https://drive.google.com/folderview?id=0B17B0rYH2zERU21sQnVweUZCUFk&usp=sharing help guides]
* [http://moodle.org/mod/forum/discuss.php?d=182086 New Video Tutorial- How to Install Moodle on Shared Hosting via cPanel (Not Fantastico)]
* [http://moodle.org/mod/forum/discuss.php?d=199542 Video Tutorial - Install Moodle on a Virtual Box from scratch]

[[es:Instalaci%C3%B3n_de_moodle]]
[[de:Installation von Moodle]]
[[fr:Installation de Moodle]]
[[ja:Moodleのインストール]]

Installing Moodle

2016-10-28T20:34:26Z

Howardsmiller: /* Hardware */

{{Template:Installing Moodle}}
''This page explains how to install Moodle. If you are an expert and/or in a hurry try [[Installation Quickstart]].''

If you just want to try Moodle on a standalone machine there are 'one-click' installers for Windows (see [[Complete install packages for Windows]]) and for OSX (see [[Complete Install Packages for Mac OS X]]) or [[ install on OS X]]. These are unsuitable for production servers.

== Requirements ==

Moodle is primarily developed in Linux using [[Apache]], [[PostgreSQL]]/[[MySQL]]/[[MariaDB]] and [[PHP]] (sometimes known as the LAMP platform). Typically this is also how Moodle is run, although there are other options as long as the software requirements of the [{{Release notes}} release] are met.

If you are installing Moodle in a Windows server, note that from php5.5 onwards, you will also need to have the Visual C++ Redistributable for Visual Studio 2012 installed from:
http://www.microsoft.com/en-us/download/details.aspx?id=30679 Visual C++] ( x86 or x64)

The basic requirements for Moodle are as follows:

=== Hardware ===
* Disk space: 200MB for the Moodle code, plus as much as you need to store content. 5GB is probably a realistic minimum.
* Processor: 1GHz (min), 2GHz dual core or more recommended.
* Memory: 512MB (min), 1GB or more is recommended. 8GB plus is likely on a large production server
* Consider separate servers for the web "front ends" and the database. It is much easier to "tune"

All the above requirements will vary depending on specific hardware and software combinations as well as the type of use and load; busy sites may well require additional resources. Further guidance can be found under [[Performance_recommendations|performance recommendations]]. Moodle scales easily by increasing hardware.

For very large sites, you are much better starting with a small pilot and gaining some experience and insight. A "what hardware do I need for 50,000 user?" style post in the forums is highly unlikely to get a useful answer.

=== Software ===

See the [{{Release notes}} release notes] in the dev docs for software requirements.

== Set up your server ==

Depending the use case a Moodle server may be anything from a Desktop PC (e.g. for testing and evaluating) to a rackmounted or [[Server cluster|clustered]] solution. As mentioned above there are lots of possibilities for installing the basic server software, some links and pointers are at [[Installing AMP]], [[Internet_Information_Services|IIS]], [[Nginx]].

It will help hugely, regardless of your deployment choices, if time is taken to understand how to configure the different parts of your software stack (HTTP daemon, database, PHP etc). Do not expect the standard server configuration to be optimal for Moodle. For example, the web server and database servers will almost certainly require optimisation to work optimally with Moodle.

If a hosting provider is being used ensure that all Moodle [{{Release notes}}#Server_requirements requirments] (such as PHP version) are met by the hosting platform before attempting the installation. It will help to become familiar with changing settings within the hosting provider's platform (e.g. PHP file upload maximums) as the options and tools provided vary.

== Download and copy files into place ==

'''IMPORTANT: While there are now a number of places you can get the Moodle code, you are strongly advised to obtain Moodle from moodle.org. If you run into problems it will be a great deal easier to support you.'''

You have two options:
* Download your required version from http://moodle.org/downloads and unzip/unpack...
* '''OR''' Pull the code from the Git repository (recommended for developers and also makes upgrading very simple):
<pre>
$ git clone --depth=1 -b MOODLE_31_STABLE git://git.moodle.org/moodle.git
</pre>

Other options you might consider:
''--depth=1'' for shallow cloning (only) latest revision

''--single-branch'' to limit cloning to a single branch, this fetches the Moodle 3.1 Stable branch (latest weekly build). For a fuller discussion see [[Git for Administrators]].

Either of the above should result in a directory called '''moodle''', containing a number of files and folders.

You can either place the whole folder in your web server documents directory, in which case the site will be located at '''<nowiki>http://yourwebserver.com/moodle</nowiki>''', or you can copy all the contents straight into the main web server documents directory, in which case the site will be simply '''<nowiki>http://yourwebserver.com</nowiki>'''. See the documentation for your system and/or web server if you are unsure.

:''Tip:'' If you are downloading Moodle to your local computer and then uploading it to your hosted web site, if possible upload the compressed file and decompress at the remote end (check your 'file manager'). Failing that, watch FTP progress carefully for errors or missed files.

* '''Secure the Moodle files:''' It is vital that the files are not writeable by the web server user. For example, on Unix/Linux (as root):
<pre>
# chown -R root /path/to/moodle
# chmod -R 0755 /path/to/moodle
# find /path/to/moodle -type f -exec chmod 0644 {} \;
</pre>
(files are owned by the administrator/superuser and are only writeable by them - readable by everyone else)

The third command finds all the regular files and executes the chmod command 0644 on them.

If you want to use the built-in plugin installer you need to make the directory writable by web server user. It is strongly recommended to use ACL when your server supports it, for example if your Apache server uses account www-data:

<pre>
# chmod -R +a "www-data allow read,delete,write,append,file_inherit,directory_inherit" /path/to/moodle
</pre>

The effect of the previous command is to allow the Apache user account (www-data in this case) to access and change files within the moodle site. Many people would consider this a brave move for a new site admin to implement. In a new moodle you can safely leave this out. A default Ubuntu install does not have the +a option for the chmod command anyway. The +a attribute is an ACL (Access Control List) facility which allows you to set per user access for individual files. For example, OSX has this by default.

== Create an empty database ==

Next create a new, empty database for your installation. You need to find and make a note of following information for use during the final installation stage:
* '''dbhost''' - the database server hostname. Probably ''localhost'' if the database and web server are the same machine, otherwise the name of the database server
* '''dbname''' - the database name. Whatever you called it, e.g. ''moodle''
* '''dbuser''' - the username for the database. Whatever you assigned, e.g. ''moodleuser'' - do not use the root/superuser account. Create a proper account with the minimum permissions needed.
* '''dbpass''' - the password for the above user

If your site is hosted you should find a web-based administration page for databases as part of the control panel (or ask your administrator). For everyone else or for detailed instructions, see the page for your chosen database server:
* [[PostgreSQL]]
* [[MariaDB]] (known issues - see MDL-45233)
* [[MySQL]] (known issues - see MDL-45233)
* [[MSSQL]]
* [[Oracle]] (known issues, not fully supported - see MDL-41310)

== Create the (''moodledata'') data directory ==

Moodle requires a directory to store all of its files (all your site's uploaded files, temporary data, cache, session data etc.). The web server needs to be able to write to this directory. On larger systems consider how much free space you are going to use when allocating this directory.

Due to the way Moodle caches data you may have performance issues if you use relatively slow storage (e.g. NFS) for this directory. Read the [[Performance_recommendations]] carefully and consider using (e.g.) memcached for [[Caching]].

'''IMPORTANT:''' This directory must '''NOT''' be accessible directly via the web. This would be a serious security hole. Do not try to place it inside your web root or inside your Moodle program files directory. Moodle will not install. It can go anywhere else convenient.

Here is an example (Unix/Linux) of creating the directory and setting the permissions for '''anyone''' on the server to write here. This is only appropriate for Moodle servers that are not shared. Discuss this with your server administrator for better permissions that just allow the web server user to access these files.

<pre>
# mkdir /path/to/moodledata
# chmod 0777 /path/to/moodledata
</pre>

If your server supports ACL it is recommended to set following permissions, for example if your Apache server uses account www-data:
<pre>
# chmod -R +a "www-data allow read,delete,write,append,file_inherit,directory_inherit" /path/to/moodledata
</pre>
If you are planning to execute PHP scripts from the command line you should set the same permissions for the current user:
<pre>
$ sudo chmod -R +a "`whoami` allow read,delete,write,append,file_inherit,directory_inherit" /path/to/moodledata
</pre>

==== Securing moodledata in a web directory ====

If you are using a hosted site and you have no option but to place 'moodledata' in a web accessible directory. You may be able to secure it by creating an .htaccess file in the 'moodledata' directory. This does not work on all systems - see your host/administrator. Create a file called .htaccess containing only the following lines:
<pre>
order deny,allow
deny from all
</pre>

== Start Moodle install ==
It's now time to run the installer to create the database tables and configure your new site. The recommended method is to use the command line installer. If you cannot do this for any reason (e.g. on a Windows server) the web based installer is still available.

=== Command line installer ===

It's best to run the command line as your system's web user. You need to know what that is - see your system's documentation (e.g. Ubuntu/Debian is 'www-data', Centos is 'apache')

* Example of using the command-line (as root - substitute 'www-data' for your web user):
<pre>
# chown www-data /path/to/moodle
# cd /path/to/moodle/admin/cli
# sudo -u www-data /usr/bin/php install.php
# chown -R root /path/to/moodle
</pre>
The chowns allow the script to write a new config.php file. More information about the options can be found using
<pre>
# php install.php --help
</pre>

You will be asked for other settings that have not been discussed on this page - if unsure just accept the defaults. For a full discussion see [[Administration via command line]]

=== Web based installer ===

For ease of use you can install Moodle via the web. We recommend configuring your web server so that the page is not publicly accessible until the installation is complete.

To run the web installer script, just go to your Moodle's main URL using a web browser.

The installation process will take you through a number of pages. You should be asked to confirm the copyright, see the database tables being created, supply administrator account details and supply the site details. The database creation can take some time - please be patient. You should eventually end up at the Moodle front page with an invitation to create a new course.

It is very likely that you will be asked to download the new config.php file and upload it to your Moodle installation - just follow the on-screen instructions.

==Final configuration==

=== Settings within Moodle ===
There are a number of options within the Moodle Site Administration screens (accessible from the 'Site administration' tab in the 'Administration' block. Here are a few of the more important ones that you will probably want to check:
* ''Administration > Site administration > Plugins > Message Outputs > Email'': Set your smtp server and authentication if required (so your Moodle site can send emails). The support contact for your site is also set on this page.
* ''Administration > Site administration > Server > System paths'': Set the paths to du, dot and aspell binaries.
* ''Administration > Site administration > Server > HTTP'': If you are behind a firewall you may need to set your proxy credentials in the 'Web proxy' section.
* ''Administration > Site administration > Location > Update timezones'': Run this to make sure your timezone information is up to date. (more info [[Location]])
** [http://php.net/manual/en/timezones.php Set server's local timezone] inside <tt>php.ini</tt> (should probably be inside <tt>/etc/php.ini</tt> or <tt>/etc/php.d/date.ini</tt>, depending on the underline OS):
**: <code ini>[Date]
; Defines the default timezone used by the date functions
date.timezone = "YOUR LOCAL TIMEZONE"</code>

=== Remaining tasks ===

* '''Configure Cron''': Moodle's background tasks (e.g. sending out forum emails and performing course backups) are performed by a script which you can set to execute at specific times of the day. This is known as a cron script. Please refer to the [[Cron|Cron instructions]].
* '''Set up backups''': See [[Site backup]] and [[Automated course backup]].
* '''Check mail works''': [[Add a new user|Create a test user]] with a valid email address and [[message|send them a message]]. Do they receive an email copy of the message? If not, check the settings in ''Settings > Site administration > Plugins > Message outputs > Email''. Don't be tempted to skip this step (clue: email is used to recover lost passwords, including the administrator password when you forget it!)
* '''Secure your Moodle site''': Read the [[Security recommendations]].
*'''Increasing the maximum upload size''' See [[Installation FAQ]] Maximum upload file size - how to change it?

=== Installation is complete :) ===

* Create a new course: You can now access Moodle through your web browser (using the same URL as you set during the install process), log in as your admin user and creatse a new course. See [[Adding a new course|create a new course]].

=== If something goes wrong... ===

Here are some things you should try...

* Check the [[Installation FAQ]]
* Check your file permissions carefully. Can your web server read (but not write) the Moodle program files? Can your web server read and write your Moodle data directory?
* Check your database permissions. Have you set up your database user with the correct rights and permissions for your configuration (especially if the web server and database server are different machines)?
* Create your [[Configuration file]] (config.php) by hand. Copy config-dist.php (in the root of the Moodle program directory) to config.php, edit it and set your database/site options there. Installation will continue from the right place.
* Once you have a config.php (see previous tip) you can edit it to turn on debugging (in section 8). This may give you extra information to help track down a problem. If you have access, check your web server error log(s).
* Re-check your php.ini / .htaccess settings. Are they appropriate (e.g. memory_limit), did you edit the correct php.ini / .htaccess file and (if required) did you re-start the web server after making changes?
* Did you include any non-core (optional) plugins, themes or other code before starting the installation script? If so, remove it and try again (it may be broken or incompatible).
* Explain your problem in the [http://moodle.org/mod/forum/view.php?id=28 Installation problems forum]. '''PLEASE''' list your software versions; explain what you did, what happened and what error messages you saw (if any); explain what you tried. There is no such thing as 'nothing', even a blank page is something!

== Platform specific instructions ==

'''Note:''' Much of this information is provided by the community. It may not have been checked and may be out of date. Please read in conjunction with the above installation instructions.

* [[Windows installation]]
** [[Installing Moodle on SmarterASP.NET]]
* [[Unix or Linux Installation]]
* [[Mac Installation]]
* [[Amazon EC2 Cloud Services Installation]]

== See also ==
* [http://www.slideshare.net/gb2048/my-own-moodle Slideshare presentation by Gareth Barnard on installing a local installation of Moodle] and accompanying [https://drive.google.com/folderview?id=0B17B0rYH2zERU21sQnVweUZCUFk&usp=sharing help guides]
* [http://moodle.org/mod/forum/discuss.php?d=182086 New Video Tutorial- How to Install Moodle on Shared Hosting via cPanel (Not Fantastico)]
* [http://moodle.org/mod/forum/discuss.php?d=199542 Video Tutorial - Install Moodle on a Virtual Box from scratch]

[[es:Instalaci%C3%B3n_de_moodle]]
[[de:Installation von Moodle]]
[[fr:Installation de Moodle]]
[[ja:Moodleのインストール]]

Installing Moodle

2016-10-28T20:20:54Z

Howardsmiller: /* Installation is complete :) */

{{Template:Installing Moodle}}
''This page explains how to install Moodle. If you are an expert and/or in a hurry try [[Installation Quickstart]].''

If you just want to try Moodle on a standalone machine there are 'one-click' installers for Windows (see [[Complete install packages for Windows]]) and for OSX (see [[Complete Install Packages for Mac OS X]]) or [[ install on OS X]]. These are unsuitable for production servers.

== Requirements ==

Moodle is primarily developed in Linux using [[Apache]], [[PostgreSQL]]/[[MySQL]]/[[MariaDB]] and [[PHP]] (sometimes known as the LAMP platform). Typically this is also how Moodle is run, although there are other options as long as the software requirements of the [{{Release notes}} release] are met.

If you are installing Moodle in a Windows server, note that from php5.5 onwards, you will also need to have the Visual C++ Redistributable for Visual Studio 2012 installed from:
http://www.microsoft.com/en-us/download/details.aspx?id=30679 Visual C++] ( x86 or x64)

The basic requirements for Moodle are as follows:

=== Hardware ===
* Disk space: 200MB for the Moodle code, plus as much as you need to store content. 5GB is probably a realistic minimum.
* Processor: 1GHz (min), 2GHz dual core or more recommended.
* Memory: 512MB (min), 1GB or more is recommended. 8GB plus is likely on a large production server
* Consider separate servers for the web "front ends" and the database. It is much easier to "tune"

All the above requirements will vary depending on specific hardware and software combinations as well as the type of use and load; busy sites may well require additional resources. Further guidance can be found under [[Performance_recommendations|performance recommendations]]. Moodle scales easily by increasing hardware.

=== Software ===

See the [{{Release notes}} release notes] in the dev docs for software requirements.

== Set up your server ==

Depending the use case a Moodle server may be anything from a Desktop PC (e.g. for testing and evaluating) to a rackmounted or [[Server cluster|clustered]] solution. As mentioned above there are lots of possibilities for installing the basic server software, some links and pointers are at [[Installing AMP]], [[Internet_Information_Services|IIS]], [[Nginx]].

It will help hugely, regardless of your deployment choices, if time is taken to understand how to configure the different parts of your software stack (HTTP daemon, database, PHP etc). Do not expect the standard server configuration to be optimal for Moodle. For example, the web server and database servers will almost certainly require optimisation to work optimally with Moodle.

If a hosting provider is being used ensure that all Moodle [{{Release notes}}#Server_requirements requirments] (such as PHP version) are met by the hosting platform before attempting the installation. It will help to become familiar with changing settings within the hosting provider's platform (e.g. PHP file upload maximums) as the options and tools provided vary.

== Download and copy files into place ==

'''IMPORTANT: While there are now a number of places you can get the Moodle code, you are strongly advised to obtain Moodle from moodle.org. If you run into problems it will be a great deal easier to support you.'''

You have two options:
* Download your required version from http://moodle.org/downloads and unzip/unpack...
* '''OR''' Pull the code from the Git repository (recommended for developers and also makes upgrading very simple):
<pre>
$ git clone --depth=1 -b MOODLE_31_STABLE git://git.moodle.org/moodle.git
</pre>

Other options you might consider:
''--depth=1'' for shallow cloning (only) latest revision

''--single-branch'' to limit cloning to a single branch, this fetches the Moodle 3.1 Stable branch (latest weekly build). For a fuller discussion see [[Git for Administrators]].

Either of the above should result in a directory called '''moodle''', containing a number of files and folders.

You can either place the whole folder in your web server documents directory, in which case the site will be located at '''<nowiki>http://yourwebserver.com/moodle</nowiki>''', or you can copy all the contents straight into the main web server documents directory, in which case the site will be simply '''<nowiki>http://yourwebserver.com</nowiki>'''. See the documentation for your system and/or web server if you are unsure.

:''Tip:'' If you are downloading Moodle to your local computer and then uploading it to your hosted web site, if possible upload the compressed file and decompress at the remote end (check your 'file manager'). Failing that, watch FTP progress carefully for errors or missed files.

* '''Secure the Moodle files:''' It is vital that the files are not writeable by the web server user. For example, on Unix/Linux (as root):
<pre>
# chown -R root /path/to/moodle
# chmod -R 0755 /path/to/moodle
# find /path/to/moodle -type f -exec chmod 0644 {} \;
</pre>
(files are owned by the administrator/superuser and are only writeable by them - readable by everyone else)

The third command finds all the regular files and executes the chmod command 0644 on them.

If you want to use the built-in plugin installer you need to make the directory writable by web server user. It is strongly recommended to use ACL when your server supports it, for example if your Apache server uses account www-data:

<pre>
# chmod -R +a "www-data allow read,delete,write,append,file_inherit,directory_inherit" /path/to/moodle
</pre>

The effect of the previous command is to allow the Apache user account (www-data in this case) to access and change files within the moodle site. Many people would consider this a brave move for a new site admin to implement. In a new moodle you can safely leave this out. A default Ubuntu install does not have the +a option for the chmod command anyway. The +a attribute is an ACL (Access Control List) facility which allows you to set per user access for individual files. For example, OSX has this by default.

== Create an empty database ==

Next create a new, empty database for your installation. You need to find and make a note of following information for use during the final installation stage:
* '''dbhost''' - the database server hostname. Probably ''localhost'' if the database and web server are the same machine, otherwise the name of the database server
* '''dbname''' - the database name. Whatever you called it, e.g. ''moodle''
* '''dbuser''' - the username for the database. Whatever you assigned, e.g. ''moodleuser'' - do not use the root/superuser account. Create a proper account with the minimum permissions needed.
* '''dbpass''' - the password for the above user

If your site is hosted you should find a web-based administration page for databases as part of the control panel (or ask your administrator). For everyone else or for detailed instructions, see the page for your chosen database server:
* [[PostgreSQL]]
* [[MariaDB]] (known issues - see MDL-45233)
* [[MySQL]] (known issues - see MDL-45233)
* [[MSSQL]]
* [[Oracle]] (known issues, not fully supported - see MDL-41310)

== Create the (''moodledata'') data directory ==

Moodle requires a directory to store all of its files (all your site's uploaded files, temporary data, cache, session data etc.). The web server needs to be able to write to this directory. On larger systems consider how much free space you are going to use when allocating this directory.

Due to the way Moodle caches data you may have performance issues if you use relatively slow storage (e.g. NFS) for this directory. Read the [[Performance_recommendations]] carefully and consider using (e.g.) memcached for [[Caching]].

'''IMPORTANT:''' This directory must '''NOT''' be accessible directly via the web. This would be a serious security hole. Do not try to place it inside your web root or inside your Moodle program files directory. Moodle will not install. It can go anywhere else convenient.

Here is an example (Unix/Linux) of creating the directory and setting the permissions for '''anyone''' on the server to write here. This is only appropriate for Moodle servers that are not shared. Discuss this with your server administrator for better permissions that just allow the web server user to access these files.

<pre>
# mkdir /path/to/moodledata
# chmod 0777 /path/to/moodledata
</pre>

If your server supports ACL it is recommended to set following permissions, for example if your Apache server uses account www-data:
<pre>
# chmod -R +a "www-data allow read,delete,write,append,file_inherit,directory_inherit" /path/to/moodledata
</pre>
If you are planning to execute PHP scripts from the command line you should set the same permissions for the current user:
<pre>
$ sudo chmod -R +a "`whoami` allow read,delete,write,append,file_inherit,directory_inherit" /path/to/moodledata
</pre>

==== Securing moodledata in a web directory ====

If you are using a hosted site and you have no option but to place 'moodledata' in a web accessible directory. You may be able to secure it by creating an .htaccess file in the 'moodledata' directory. This does not work on all systems - see your host/administrator. Create a file called .htaccess containing only the following lines:
<pre>
order deny,allow
deny from all
</pre>

== Start Moodle install ==
It's now time to run the installer to create the database tables and configure your new site. The recommended method is to use the command line installer. If you cannot do this for any reason (e.g. on a Windows server) the web based installer is still available.

=== Command line installer ===

It's best to run the command line as your system's web user. You need to know what that is - see your system's documentation (e.g. Ubuntu/Debian is 'www-data', Centos is 'apache')

* Example of using the command-line (as root - substitute 'www-data' for your web user):
<pre>
# chown www-data /path/to/moodle
# cd /path/to/moodle/admin/cli
# sudo -u www-data /usr/bin/php install.php
# chown -R root /path/to/moodle
</pre>
The chowns allow the script to write a new config.php file. More information about the options can be found using
<pre>
# php install.php --help
</pre>

You will be asked for other settings that have not been discussed on this page - if unsure just accept the defaults. For a full discussion see [[Administration via command line]]

=== Web based installer ===

For ease of use you can install Moodle via the web. We recommend configuring your web server so that the page is not publicly accessible until the installation is complete.

To run the web installer script, just go to your Moodle's main URL using a web browser.

The installation process will take you through a number of pages. You should be asked to confirm the copyright, see the database tables being created, supply administrator account details and supply the site details. The database creation can take some time - please be patient. You should eventually end up at the Moodle front page with an invitation to create a new course.

It is very likely that you will be asked to download the new config.php file and upload it to your Moodle installation - just follow the on-screen instructions.

==Final configuration==

=== Settings within Moodle ===
There are a number of options within the Moodle Site Administration screens (accessible from the 'Site administration' tab in the 'Administration' block. Here are a few of the more important ones that you will probably want to check:
* ''Administration > Site administration > Plugins > Message Outputs > Email'': Set your smtp server and authentication if required (so your Moodle site can send emails). The support contact for your site is also set on this page.
* ''Administration > Site administration > Server > System paths'': Set the paths to du, dot and aspell binaries.
* ''Administration > Site administration > Server > HTTP'': If you are behind a firewall you may need to set your proxy credentials in the 'Web proxy' section.
* ''Administration > Site administration > Location > Update timezones'': Run this to make sure your timezone information is up to date. (more info [[Location]])
** [http://php.net/manual/en/timezones.php Set server's local timezone] inside <tt>php.ini</tt> (should probably be inside <tt>/etc/php.ini</tt> or <tt>/etc/php.d/date.ini</tt>, depending on the underline OS):
**: <code ini>[Date]
; Defines the default timezone used by the date functions
date.timezone = "YOUR LOCAL TIMEZONE"</code>

=== Remaining tasks ===

* '''Configure Cron''': Moodle's background tasks (e.g. sending out forum emails and performing course backups) are performed by a script which you can set to execute at specific times of the day. This is known as a cron script. Please refer to the [[Cron|Cron instructions]].
* '''Set up backups''': See [[Site backup]] and [[Automated course backup]].
* '''Check mail works''': [[Add a new user|Create a test user]] with a valid email address and [[message|send them a message]]. Do they receive an email copy of the message? If not, check the settings in ''Settings > Site administration > Plugins > Message outputs > Email''. Don't be tempted to skip this step (clue: email is used to recover lost passwords, including the administrator password when you forget it!)
* '''Secure your Moodle site''': Read the [[Security recommendations]].
*'''Increasing the maximum upload size''' See [[Installation FAQ]] Maximum upload file size - how to change it?

=== Installation is complete :) ===

* Create a new course: You can now access Moodle through your web browser (using the same URL as you set during the install process), log in as your admin user and creatse a new course. See [[Adding a new course|create a new course]].

=== If something goes wrong... ===

Here are some things you should try...

* Check the [[Installation FAQ]]
* Check your file permissions carefully. Can your web server read (but not write) the Moodle program files? Can your web server read and write your Moodle data directory?
* Check your database permissions. Have you set up your database user with the correct rights and permissions for your configuration (especially if the web server and database server are different machines)?
* Create your [[Configuration file]] (config.php) by hand. Copy config-dist.php (in the root of the Moodle program directory) to config.php, edit it and set your database/site options there. Installation will continue from the right place.
* Once you have a config.php (see previous tip) you can edit it to turn on debugging (in section 8). This may give you extra information to help track down a problem. If you have access, check your web server error log(s).
* Re-check your php.ini / .htaccess settings. Are they appropriate (e.g. memory_limit), did you edit the correct php.ini / .htaccess file and (if required) did you re-start the web server after making changes?
* Did you include any non-core (optional) plugins, themes or other code before starting the installation script? If so, remove it and try again (it may be broken or incompatible).
* Explain your problem in the [http://moodle.org/mod/forum/view.php?id=28 Installation problems forum]. '''PLEASE''' list your software versions; explain what you did, what happened and what error messages you saw (if any); explain what you tried. There is no such thing as 'nothing', even a blank page is something!

== Platform specific instructions ==

'''Note:''' Much of this information is provided by the community. It may not have been checked and may be out of date. Please read in conjunction with the above installation instructions.

* [[Windows installation]]
** [[Installing Moodle on SmarterASP.NET]]
* [[Unix or Linux Installation]]
* [[Mac Installation]]
* [[Amazon EC2 Cloud Services Installation]]

== See also ==
* [http://www.slideshare.net/gb2048/my-own-moodle Slideshare presentation by Gareth Barnard on installing a local installation of Moodle] and accompanying [https://drive.google.com/folderview?id=0B17B0rYH2zERU21sQnVweUZCUFk&usp=sharing help guides]
* [http://moodle.org/mod/forum/discuss.php?d=182086 New Video Tutorial- How to Install Moodle on Shared Hosting via cPanel (Not Fantastico)]
* [http://moodle.org/mod/forum/discuss.php?d=199542 Video Tutorial - Install Moodle on a Virtual Box from scratch]

[[es:Instalaci%C3%B3n_de_moodle]]
[[de:Installation von Moodle]]
[[fr:Installation de Moodle]]
[[ja:Moodleのインストール]]

Security keys

2016-10-07T09:02:49Z

Howardsmiller: Vital information missing

{{RSS feeds}}
A security key or token enables other systems to access Moodle securely. A security key may be used for secure RSS feeds or web services.

A user can obtain a security key via the Preferences link of the user menu top right and then entering the key in an external application accessing Moodle.

'''Note: In order for this to be accessible the user needs the moodle/webservice:create token capability. The easiest way to do this is to allow the capability for the Authenticated User role. This does not allow the user to use web services, only to create a token.'''

At any time, a user can reset their key by clicking the reset link. A new different key is automatically generate which will then need to be entered in the external application.

'''Note:''' The security keys page can not generate web service keys/tokens for admins. Admins can create a token manually from the administration block: '' Site administration > Plugins > Web services > Manage tokens''.

==Secure RSS feeds==

Secure RSS feeds are a way you can read [[Using_RSS_feeds|forum posts, blog entries, etc]] while you are offline, and without having to log in. For example, if you want to read the posts in a forum, you usually need to log in to Moodle. But if your site administrator has [[RSS_feeds_settings|enabled RSS]], these posts are available as a feed you can subscribe to with a [http://en.wikipedia.org/wiki/Comparison_of_feed_aggregators feed reader], and you can read entries even when you don't have access to the Internet.

Secure RSS feeds allow your feed reader, which usually expects feeds to be publicly available, to download material from Moodle without having to log in.

Whenever you are viewing an activity that provides an RSS feed, look in the Administration block for a link labelled "RSS feed of posts". This link is unique to your Moodle account. Paste it into your feed reader to have it obtain new entries for you automatically.

If you ever think your RSS feed token has been compromised in some way, e.g. you have lost a mobile phone that subscribed to a news forum, you can request a new one by clicking the ''Reset'' link on the ''Security Keys'' page from the Preferences link in your user menu. This will disable the old feed token and generate a new one. You can then visit the activities you wish to subscribe to and copy the URL, which will contain your new security key.

[[Category:Web Services]]

[[ja:セキュリティキー]]
[[es:Claves de seguridad]]

PHP

2016-09-21T09:45:56Z

Howardsmiller: /* PHP Settings */

{{Installing Moodle}}
PHP is the scripting language in which Moodle is developed. It is integrated with your web server. The web server detects php pages (by their extension) and sends them to PHP for execution. PHP must be installed and configured properly for Moodle to work effectively (or at all).

==PHP Settings==
Check these settings in your php.ini or .htaccess file (if you're using Apache). For settings which use ON/OFF as their values, you can substitute 1 for ON and 0 for OFF if you prefer. If you change php.ini, don't forget to restart the server.
* ''register_globals'' '''MUST''' be OFF - (Feature removed as of PHP 5.4. PHP 5.4 is a minimum requirement of Moodle 2.7)
* ''safe_mode'' needs to be OFF - (Feature removed as of PHP 5.4. PHP 5.4 is a minimum requirement of Moodle 2.7)
* ''memory_limit'' needs to be at least 96M (although some functions may not work if this low). Moodle will refuse to install if lower. 128M is recommended. Large systems may need an even higher setting.
* ''session.save_handler'' needs to be set to FILES.
* ''magic_quotes_gpc'' should be OFF - (Feature removed as of PHP 5.4. PHP 5.4 is a minimum requirement of Moodle 2.7)
* ''magic_quotes_runtime'' needs to be OFF.
* ''file_uploads'' needs to be ON.
* ''session.auto_start'' needs to be OFF.
* ''session.bug_compat_warn'' needs to be OFF - (Feature removed as of PHP 5.4. PHP 5.4 is a minimum requirement of Moodle 2.7)
* The temp folder must be defined and writeable by your webserver user
* Check the error display/logging section. Make sure the settings are appropriate for your server use.
* ''post_max_size'' and ''upload_max_filesize'' restrict the maximum file size that can be uploaded.
* Check the ''[mail function]'' and database section (for your chosen database) to make sure they match your server configuration.

==HTTP_RAW_POST_DATA errors==
Some users are experiencing $HTTP_RAW_POST_DATA related errors, when establishing connection between MNET servers or making AJAX web services requests.
<pre>
Request for server name returned empty response

line 134 of /mnet/lib.php: call to debugging()
line 115 of /admin/mnet/peers.php: call to mnet_get_public_key()
</pre>

These errors are affecting users running moodle on PHP 5.6 version and it's a PHP bug on the '''always_populate_raw_post_data''' setting the default value to 0.

To avoid the error messages above, please change the value following setting on your php.ini file:
* '''always_populate_raw_post_data''' should be changed to '''-1'''.

For more information about this bug, see: https://bugs.php.net/bug.php?id=66763

==Finding the correct php.ini==
Sometimes it is not obvious where the php.ini file is located or you may even find more than one. To be certain run 'phpinfo' - see below. The path of the php.ini file is a few lines down in the top section.

Note that if you are using command-line (CLI) PHP for running cron (or anything else) it may be configured with a ''different'' php.ini file. To check, run the following command:
<pre>
php -i | grep php.ini
</pre>

==PHP Extensions and libraries==
The following PHP extensions are required or recommended (some, e.g. iconv, ctype and tokenizer are now included in PHP by default). Others will need to be installed or selected.
* The '''iconv''' extension is required.
* The '''mbstring''' extension is recommended.
* The '''curl''' extension is required (required for networking and web services).
* The '''openssl''' extension is recommended (required for networking and web services).
* The '''tokenizer''' extension is recommended.
* The '''xmlrpc''' extension is recommended (required for networking and web services).
* The '''soap''' extension is recommended (required for web services).
* The '''ctype''' extension is required.
* The '''zip''' extension is required.
* The '''gd''' extension is recommended (required for manipulating images).
* The '''simplexml''' extension is required.
* The '''spl''' extension is required.
* The '''pcre''' extension is required.
* The '''dom''' extension is required.
* The '''xml''' extension is required.
* The '''intl''' extension is recommended.
* The '''json''' extension is required.
* '''The appropriate extension for your chosen database is also required.'''

* Other PHP extensions may be required to support optional Moodle functionality, especially external authentication and/or enrolment (e.g. LDAP extension for LDAP authentication and the sockets extension for Chat server).

==Installing (missing) extensions==

This depends on how PHP was installed on your machine and what access you have. Here are some possibilities:
* If this is a hosted server you are likely to have to ask the administrator or hosting company.
* If PHP was compiled from source you will need to recompile, changing the 'configure' settings - see [[Compiling PHP from source]].
* If it was installed using packages (typically Linux) you can install the required package (see your Linux distribution's documentation)
* If you are using Windows you just need to uncomment the appropriate DLL files in php.ini

After making any changes or additions, don't forget to re-start your web server.

== .htaccess files ==

If you don't have access to the php.ini file or there are conflicting requirements with other PHP applications on the same server you may be able to change PHP settings in an .htaccess file. This should be placed in the 'root' of your Moodle installation (i.e. the same place as the config.php file).

'''The file isn't always called .htaccess and may not work at all. Contact your server administrator to be sure'''

Settings are made by adding lines in one of two formats:
* php_value ''name value''
* php_flag ''name on/off''

Examples:
* '''php_value memory_limit 128M'''
* '''php_flag register_globals off'''

==PHP info==

The phpinfo display contains information about the configuration of your PHP installation. This is useful for checking:
* that your PHP installation meets Moodle's system requirements.
* the values that are currently applied to your server's PHP install, e.g. File upload limits
* that you have installed the required modules needed for Moodle to work, e.g. the LDAP module for LDAP authentication.

=== Displaying phpinfo in Moodle===

An administrator can find PHP info in ''Settings > Site administration > Server > PHP info''.

=== Displaying phpinfo outside of Moodle ===

To view the phpinfo information:
* Create a file called info.php using your text editor, containing this single line:

<code php>
<?php phpinfo(); ?>
</code>

* Save this file as info.php
* Upload this file into the root web accessible folder on your server.
* Now open this file in your browser. For example <nowiki>http://<server-name>/info.php</nowiki>.

==See also==

*[[Compiling PHP from source]]
* [https://docs.moodle.org/dev/Moodle_and_PHP7 Moodle and PHP7] in the developers documentation
*http://www.php.net/ - the PHP web site
*http://php.iis.net/ - Microsoft PHP Installer for IIS

[[de:PHP-Versionen für Moodle]]
[[es:PHP]]

admin/environment/php setting/memory limit

2016-09-19T09:06:08Z

Howardsmiller:

{{Environment}}
''memory_limit'' should be at least 96M. Large sites may need much more. PHP 5.2.x requires higher memory_limit values than previous versions of PHP. 64bit operating systems require even more memory.

[[Category:Environment|PHP]]

[[es:admin/environment/php setting/memory limit]]