MoodleDocs - Användarbidrag [sv]

Ratingallocate

2021-09-05T22:51:21Z

Drcuriosity: /* General */ Section rewrite to clarify the high-level purpose and features of the plugin.

{{Infobox plugin
|type = Activity
|entry = https://moodle.org/plugins/view/mod_ratingallocate
|tracker = https://github.com/learnweb/moodle-mod_ratingallocate
|discussion = https://moodle.org/mod/forum/discuss.php?d=308418
|maintainer = [[User:University of Münster|University of Münster]]
|float = right
}}

==General==
This plugin provides the ability to distribute various resources among users, while aiming to maximize overall user satisfaction with the distribution.

The plugin creates a rating allocation activity, where administrators define multiple choices that can be rated by users enrolled in the course. Several rating strategies can be selected.

When the rating period has ended, an algorithm automatically calculates the best distribution of choices based on the users' preferences. Users can then be assigned to groups based on their allocated choices.

Possibilities for resources to be distributed with this plugin:
* Tutorial groups
* Thesis or project topics
* Seminar time slots

==Steps to take==
This chapter should give a guideline how the plugin "Fair Allocation" can be used and which steps have to be done in its life-cycle.
# Add a "Fair Allocation" instance to your course and configure it. (See the section "Settings")
# Add choices to your instance. (See the section "Edit Choices")
# After the rating period started users will start edit their ratings.
# After the rating period has ended:
## Start distribution (If not done automatically. See "Additional Settings")
## Adjust the allocation to your own needs. (See "Alter Allocation")
## If you want, you can create now moodle groups from the allocation. The users will be automatically be assigned to their respective group.
## Publish the allocation

In the section "Reports" the link "Show Ratings and Allocations" shows the current ratings and allocations.
Here it is also possible to download the results in different data-formats (csv, xlsx, ods, html, json).
Under "Show Allocation Statistics" you can see, how many first, second,... wishes could be fulfilled and how many students are still unassigned.

==Alter Allocation==
The algorithm is only as good as the settings he can work with. Often after the allocation is made by the algorithm some choices are booked completely and some are booked only sparsely.
Sometimes it is hard to guess the exact number of students participating in the "Fair Allocation" at setup time. Then the sizes of the choices might be too high or too low.
If you have too many places you can react in two ways:
* If the sizes of the choices are flexible adjust the sizes and start the algorithm again. Then the students will be distributed more evenly.
* If the choices are fixed, disable some choices and start the algorithm again. Then the students will be distributed only on the remaining choices.
Another reason for sparsely booked choices can be that most of the students rated this choice with the lowest possible rating (depending on the strategy). This is an indicator for the algorithm that this choice will not be assigned to this student. For this reason, some students might have been left unassigned. It is useful to check this and then assign these students manually.

In the manual allocation screen, you can alter the allocation of each single student. Here you see for each student, how he rated each choice and which choice he is currently assigned to. In the default filter settings, only those students are displayed, which have rated. You can alter the filter settings by checking or unchecking the two settings and then hit "Update Filter". This way you can for example also hide all students, which are already allocated, to focus on those, who still need to be assigned. You can also search for specific students by using the initial filters.
Changes to the allocations are only persisted after the form is saved! While you alter the allocations, the green color of the checkbox border and the bold font of the rating text indicate the choice the student was assigned to before you started altering it.

When you want to delete an allocation just uncheck the specific choice and save the form.

==Settings==
In the settings there are various possibilities to adjust the activity to the own needs. In the following all plugin specific settings are described in the view of the effect they have on the activity.
===Rating strategy===
The rating strategy is one of the core settings of the "Fair Allocation" plugin. It specifies the way the users can rate upon the available choices. There are six different strategies available:
* '''Accept-Deny''' The user can rate each choice with accept or deny.
* '''Accept-Neutral-Deny''' The user can rate each choice with accept, neutral or deny.
* '''Likert Scale''' The user can rate each choice within a scale of integers. The size of the scale can be adjusted in the individual strategy (beginning with 0). A high number means a high preference.
* '''Give Points''' The user can rate the choices by assigning a number of points. The maximum number of points can be set in the individual strategy options. The choice with the most points is preferred.
* '''Rank Choices''' The user has to state and order his ''N'' highest preferences. How many choices need to be rated can be set in the individual strategy options.
* '''Tick Accept''' The user can state for each choice if it is acceptable for him.

In the background each selection option is assigned to an integer value for the use within the algorithm.

===Dates===
There are three dates, which are of interest for the underlying process of a "Fair Allocation" activity.

* '''Rating begins at''' This date states the time, when the rating period is opened. Before this time no user will be able to edit his rating.
* '''Rating ends at''' This date states the time, when the rating period is closed. After this time users are no longer able to create or edit their rating. In addition, all further steps of distribution offered to the teacher are only enabled after the rating period ended.
* '''Publishdate''' This date has no effect on the process of the activity but offers the teacher a possibility to communicate the expected publish-date. This date can be disabled.

===Strategy Options===
Each strategy offers individual settings, which are only enabled for editing, when the respective strategy is chosen. There are some options many strategies have in common:
* '''Label''' It is possible to assign individual labels to each selection option. However, when no value is set here the activity will take the default value, which makes it possible to display language specific labels.
* '''Maximum number of choices the user can rate with...''' Here a number can be added, restricting the number of choices the user can decline. Internally the selection options "deny", 0 etc. are assigned to the value 0. The algorithm will make no assignment of a user to a choice he has rated with 0. To decrease the number of users, which could not be assigned to any choice according to their wished, the users should be forced to rate on a reasonable number of choices. Each user, who could not be assigned via the algorithm has to be allocated manually afterwards!

Some of the options however are very specific to the respective strategy:

* '''Highest number on the lickert-scale (lickert-scale)''' This number configures who many selection options the users get. The scale starts always with 0 and ranges up to this value. The refresh button on the bottom enables to refresh the number of fields offered for the individual labels.
* '''Total number of points users can assign (Give Points)''' This option states the number of points a user can and has to assign. All points have to add up to this number.
* '''Number of fields the user is presented to vote on (Rank Choices)''' This option specifies the number of choices the user has to rate. For example, the number 3 means, that the user has to specify and order his top 3 choices.

===Additional Settings===
* '''Automatic allocation after rating period''' If checked, the algorithm will start to generate the allocation directly after the rating period ended. This way, the allocation may be already finished when you next visit the course. However, the allocation will not yet be published, so you have time to look at the result and alter it manually.

==Edit Choices==
Directly after the creation of the Fair Allocation instance you should follow "Edit Choices". Here it is possible to create an arbitrary number of choices using the "Add new choice" button. Each choice has individual settings:
* '''Title''' The title to be displayed for the choice.
* '''Explanation''' The explanation should provide additional information to the choice.
* '''Max number of members''' This field restricts the number of members, who can be assigned to this choice to a certain value. This is necessary for the algorithm in order to provide a good distribution. If there are no restrictions to the size, it is not necessary trying to optimize the distribution. This settings does however not prohibit an overbooking through the manual allocation.
* '''Active''' It is possible to mark choices as inactive. This feature can be valuable if a course is duplicated over multiple semesters and one choice should be excluded for only one semester. Inactive choices will not be considered in the allocation of the algorithm and will not be available for manual allocation.

==Contributors==
The plugin is based on the group_distribution plugin of the University of Ulm (Germany) and is further developed and maintained by the University of Münster (Germany)

Debugging

2021-06-03T05:15:45Z

Drcuriosity: Added a note about debugging() for developers, since it was hard to find details in search.

{{Developer tools}}
==Using debugging messages==

Debugging messages are intended to help diagnose problems and/or help Moodle developers. If you have a problem with your Moodle site and ask for help in a Moodle.org forum, a developer may ask you to turn enable debugging i.e. turn debugging messages on, in order to locate the cause of the problem. If you are having problems such as a blank screen or incomplete screens, then turning on debugging is usually the first thing to try.

==Enabling debugging==

To enable debugging, go to ''Site administration > Development > Debugging'' .

===Debug messages===

The options are:

* NONE: Do not show any errors or warnings (Default)
* MINIMAL: Show only fatal errors
* NORMAL: Show warnings, errors and notices
* ALL: Show all reasonable PHP debug messages
* DEVELOPER: extra Moodle debug messages for developers

Notes:

# It is recommended that a record of error messages is kept, and for the admin to regularly monitor the error logs. This may be done by setting 'Debug messages' (debug) to Normal and leaving 'Display debug messages' (debugdisplay) off (unticked). Error messages are then recorded in the server logs.
# If 'Debug messages' is set to Developer on a production (public) site, it is recommended to copy and paste the debugging message obtained and then turn off Developer debugging. This is because debugging messages can give clues to a hacker as to the set-up of your site.

===Display debug messages===

If you select this checkbox, the debug messages are displayed directly in the browser, otherwise they are stored in the server logs.

===Debug email sending===

Determines whether or not to enable verbose debug information during sending of email messages to SMTP server.

==== More tools for debugging outgoing mail (SMTP) ====
You can also use the config.php file to turn on more "tools" which will assist you with debugging the outgoing emails (and SMTP server configuration):
* Redirect all outgoing emails to a specific address:
<code php>
// Divert all outgoing emails to this address to test and debug emailing features
// $CFG->divertallemailsto = 'root@localhost.local'; // NOT FOR PRODUCTION SERVERS!
</code>

* Turn on the CRON debugging and run CLI cron.php script.
<code php>
// Force developer level debug and add debug info to the output of cron
// $CFG->showcrondebugging = true;
</code>
And then use SSH (or putty.exe, on windows) to run:
<code php>
you@moodle-server(/var/www/html/moodle)# php admin/cli/cron.php
</code>

* Turn on verbose SMTP debugging and output it into system's error_log (code hack):
As [https://moodle.org/mod/forum/discuss.php?d=316222#p1289850 suggested] on Moodle's discussion forums:
Open [https://github.com/moodle/moodle/blob/master/lib/moodlelib.php#L5379 lib/moodlelib.php L5379] and change it to:
<code php>
if (!empty($CFG->debugsmtp)) {
$mailer->SMTPDebug = 1; // 0 - no debug ... 4 - low level full debug
$mailer->Debugoutput = "error_log";
}
</code>
See more info about [https://github.com/moodle/moodle/blob/master/lib/phpmailer/class.phpmailer.php#L314 SMTPDebug] parameters & [https://github.com/moodle/moodle/blob/master/lib/phpmailer/class.phpmailer.php#L328 Debugoutput] parameters,
Set-up mailcatcher (https://mailcatcher.me/).

===Performance info===

The Performance info option determines whether performance info will be included in the footer of the standard theme (and some other themes). Performance info includes the time for the page to load, the amount of memory used to generate the page, cpu usage, load, and the record cache hit/miss ration.

If you add
<code php>
define('MDL_PERF', true);
define('MDL_PERFDB', true);
define('MDL_PERFTOLOG', true);
define('MDL_PERFTOFOOT', true);
</code>
to your config.php file, then it will also count database queries. (This has to be in config.php, because Moodle starts doing DB queries before it loads the config information in the database!)

To hide performance info from ordinary users, see the discussion [https://moodle.org/mod/forum/discuss.php?d=358032 Performance info only for admins?]

===Show origin of languages strings===

Helps with [[:dev:Translation|translation]] and also with [[Language customization]]. Sometimes <code>?strings=1</code> should be added; other times <code>&strings=1</code>. See the Wikipedia article [http://en.wikipedia.org/wiki/Query_string Query string] for details.

===Show validator links===
Be careful, read the warning.

===Show page information===
To show page information printed in the page footer.

===Debug SQL queries===
You can add (turn ON) any of the following dboptions in your config.php files, which log different types of SQL queries into mdl_log_queries table:
* '''logall''' - log all queries - suitable only for developers, causes high server loads and NOT recommended for production.
* '''logslow''' - log queries that take longer than specified number of seconds (float values are accepted).
* '''logerrors''' - log all error queries.

Full sample:
<code php>
$CFG->dboptions = array (
//'logall' => true,
'logslow' => 5,
'logerrors' => true,
);
</code>

==What to do if you cannot get to the admin screens==

If the error is stopping you even getting to the admin screens to turn on debugging, then you can set the debugging setting manually.

===Try typing the URL directly===

The debug settings are at the URL <code><nowiki>http://.../admin/settings.php?section=debugging</nowiki></code> on your server. Sometimes that URL will work, even though the pages you need to go to get there (for example the site front page) do not. So it is worth trying to enter that URL directly.

===In config.php===

In [[Configuration file|config.php]] you can uncomment lines (delete the // at the start of the line) under Section 7 to enable debugging for all or just specific users:

<code php>
//=========================================================================
// 7. SETTINGS FOR DEVELOPMENT SERVERS - not intended for production use!!!
//=========================================================================
//
// Force a debugging mode regardless the settings in the site administration
// @error_reporting(E_ALL | E_STRICT); // NOT FOR PRODUCTION SERVERS!
// @ini_set('display_errors', '1'); // NOT FOR PRODUCTION SERVERS!
// $CFG->debug = (E_ALL | E_STRICT); // === DEBUG_DEVELOPER - NOT FOR PRODUCTION SERVERS!
// $CFG->debugdisplay = 1; // NOT FOR PRODUCTION SERVERS!
//
// You can specify a comma separated list of user ids that that always see
// debug messages, this overrides the debug flag in $CFG->debug and $CFG->debugdisplay
// for these users only.
// $CFG->debugusers = '2';
</code>

Remember to comment those lines again (reinsert the // at the start of the line) when you have finished diagnosing your problem.

'''NOTE 1''': do not try to modify the config database table directly, it will not work because the values are cached in MUC.

'''NOTE 2''': if you find your config.php does not have the above settings (you have a cut down approx 30 lines config.php) look for a "config-dist.php" file that contains the full details. I would suggest transferring your details in the current config.php file you have into the full config file and renaming that one to "config.php".

==See also==

* If you are a developer looking for usage information on the <tt>debugging()</tt> statement, try lib/weblib.php for documentation on how it is used, and lib/setuplib.php for definitions of which PHP error levels the <tt>DEBUG_*</tt> flags map to.
* Developers can also use [http://xdebug.org/ XDEBUG] (Installed as a module on the Apache server) to further dig into the code, step by step using an [http://xdebug.org/docs/remote XDEBUG client application]. Probably, as part of their favorite IDE. For example: [http://php.netbeans.org/ NetBeans], [http://www.jetbrains.com/phpstorm/ phpStorm] or...

[[es:Depuración]]
[[fr:Débogage]]
[[de:Debugging]]

Maintenance mode

2019-09-15T22:26:43Z

Drcuriosity: /* Outage manager additial plugin */ Should be 'additional', I think.

{{Server settings}}
==Preventing access whilst maintenance is taking place==
Maintenance mode is for preventing any users other than administrators from using the site while maintenance is taking place, though ''it's not designed to prevent user access during version upgrades''.

When users attempt to access a course when your site is in maintenance mode, they obtain a message informing them that the site is in maintenance mode. If you wish, you can create a customized maintenance mode message, perhaps stating when the site will be available again or giving the reason for doing maintenance.

Note: The front page of your site will appear as normal when your site is in maintenance mode. Users will only see the maintenance mode message when they attempt to access a course.

==Setting maintenance mode==

An administrator can put the site into maintenance mode in ''Administration > Site administration > Server > Maintenance mode''.

When a site is in maintenance mode, the link "In Maintenance Mode" is displayed near the top right of each page (except the front page) for admins.

If your session finished while still in Mainenance mode, you can re-login by typing the login URL directly (<nowiki>http://yoursitename/login/</nowiki>)

==CLI maintenance mode==

Admins can enable CLI maintenance mode by adding a file <tt>$CFG->dataroot/climaintenance.html</tt>. If it exists, this file will be sent to the navigator instead of the standard Moodle home page.
The difference from the standard maintenance mode is that all web access is prevented, CLI scripts continue to work (with the exception of admin/cli/cron.php). This CLI maintenance mode is often used during CLI version upgrades.

It is possible to use the admin/cli/maintenance.php to schedule the CLI maintenance mode and then to display a message to users warning them when the site will become unavailable. In the scheduled maintenance mode, the maintenance message is taken from admin setting, template file <tt>$CFG->dataroot/climaintenance.template.html</tt> and the language pack, in this order. See MDL-37596 for details.
{|
|[[File:maintenancecli25.png|thumb|Scheduled maintenance mode]]
|}
See also the section on maintenance mode in [[Administration via command line]].

==Allowing non-admin users access to site whilst in maintenance mode==

Non-admin users may be given access to the site whilst in maintenance mode as follows:

# Create a new role with the capability [[Capabilities/moodle/site:maintenanceaccess|moodle/site:maintenanceaccess]] allowed
# Assign it to selected users as a system role

==Outage manager additional plugin==
This is a Moodle plugin which makes the student experience of planned outages nicer, and provides extra tools for administrators and testers that help before and after the outage window.

The main idea is that instead of an outage being a very boolean on/off situation, this plugin creates the concept of graduated outages where at predefined times before an outage and after, different levels of warning and access can be provided to students and testers letting them know what is about to happen and why.

See [https://moodle.org/plugins/auth_outage Outage manager] - A plugin to manage outage periods, such as scheduled maintenance, including CLI tools to embed in your scripting.

==See also==

Forum discussions:
*[https://moodle.org/mod/forum/discuss.php?d=245299 Maintenance mode cannot be switched off]
*[https://moodle.org/mod/forum/discuss.php?d=251954 Moodle for Windows stuck in Maintenance mode]
*[https://moodle.org/mod/forum/discuss.php?d=318890 Turned on Maintenance and can't get back in]

[[es:Modo de mantenimiento]]
[[fr:Mode de maintenance]]
[[ja:メンテナンスモード]]
[[de:Wartungsmodus]]

Installing Moodle

2019-09-08T21:42:18Z

Drcuriosity: /* Settings within Moodle */ underline OS -> underlying OS

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

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 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''' (New in 3.7): 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のインストール]]