MoodleDocs - User contributions [en]

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

Installing Moodle

2016-08-18T14:26:50Z

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.

=== 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 [[Adding a new course|create a new course]] and have a play ;-)

=== 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-08-18T14:25:18Z

Howardsmiller: Removing some 'wordiness' and some poor grammar.

{{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>
--depth=1 for shallow cloning (only) latest revision

--single-branch option 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 [[Adding a new course|create a new course]] and have a play ;-)

=== 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-08-18T14:21:57Z

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.

=== 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). For example it is important that the HTTP daemon is configured to support [[Using slash arguments| slash arguments]].

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, otherwise all the core configuration should be done. It will be helpful to become familiar with how to change setting within the hosting providers platform (e.g. PHP file upload maximums) as the options and tools provided can vary a huge amount between them.

== 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>
--depth=1 for shallow cloning (only) latest revision

--single-branch option 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 [[Adding a new course|create a new course]] and have a play ;-)

=== 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のインストール]]

Administration via command line

2016-06-09T09:55:00Z

Howardsmiller: /* Tool for converting tables */

{{Installing Moodle}}
==Running CLI scripts==
If you have shell access to your web server, you may find various CLI (command line interface) scripts useful during Moodle administration. Core admin CLI tools are located in the <code>admin/cli/*</code> folder. Other plugins provide their CLI functionality via scripts in their own cli folder. For example, the enrol_db sync script is located in <code>enrol/db/cli/</code>.

To avoid problems with access control, you should run them as the owner of the web server process. It is especially important for CLI installation and upgrade as they create new files in moodledata directory and the web server has to have write access to them. In Linux distributions, the user that runs the web server is usually apache or wwrun or httpd or something similar. As a root, you will probably want to execute Moodle CLI scripts like this:

$ cd /path/to/your/moodle/dir
$ sudo -u apache /usr/bin/php admin/cli/somescript.php --params

Most of the scripts accept common --help (or -h) parameter to display the full usage information, for example:

$ sudo -u apache /usr/bin/php admin/cli/install.php --help

== Upgrading ==

Moodle can be upgraded from the command line. As with the installation script, there is either interactive or non-interactive mode of the upgrade. The script itself does not put the site into the maintenance mode, you have to do it on your own. Also, the script does not backup any data (if you read this page, you probably have some own scripts to backup your moodledata and the database, right?)

$ sudo -u apache /usr/bin/php admin/cli/upgrade.php

Upgrading via command line is a very comfortable way of Moodle upgrade if you use Git checkout of the Moodle source code (see [[Git for Administrators]]). See the following procedure how to upgrade your site within several seconds to the most recent version while preserving your eventual local customizations tracked in git repository:

$ cd /var/www/sites/moodle/htdocs/
$ sudo -u apache /usr/bin/php admin/cli/maintenance.php --enable
$ git pull
$ sudo -u apache /usr/bin/php admin/cli/upgrade.php
$ sudo -u apache /usr/bin/php admin/cli/maintenance.php --disable

== Installation ==

There are two modes of installing Moodle from the command line. In interactive mode, the install script asks you for all data needed to properly set up new Moodle site. In non-interactive mode, you must provide all required data as the script parameters and then the new site is installed silently. The parameters can be passed in the interactive mode, too. The provided values are then used as the default values during the interactive session.

$ sudo -u apache /usr/bin/php admin/cli/install.php --lang=cs

If required, the database install may be skipped, with just config.php populated.

$ sudo -u apache /usr/bin/php admin/cli/install.php --skip-database

== Maintenance mode ==

To switch your site into the maintenance mode via CLI, you can use

$ sudo -u apache /usr/bin/php admin/cli/maintenance.php --enable

To turn maintenance mode off, just execute the same script with --disable parameter.

== Offline mode ==

In some situations, you may want to switch your Moodle site into offline mode so that it is not accessible via the web but you can not stop the web server completely (typically because there are other web pages and applications running there). If a file called <code>climaintenance.html</code> exists in the root folder of moodledata directory, Moodle will automatically display the contents of that file instead of any other page.

$ cd /var/www/sites/moodle/moodledata/
$ echo '<h1>Sorry, maintenance in progress</h1>' > climaintenance.html

You can prepare a nice formatted HTML page to inform your users about the server being down and keep in the moodledata directory under a name like <code>climaintenance.off</code> and rename it to the <code>climaintenance.html</code> if needed.

== Custom site defaults ==

During the install and upgrade via CLI, Moodle sets the administration variables to the default values. You can use different defaults. See MDL-17850 for details. Shortly, all you need to do is to add a file <code>local/defaults.php</code> into your Moodle installation. The format of the file is like

<code php>
<?php
$defaults['pluginname']['settingname'] = 'settingvalue'; // for plugins
$defaults['moodle']['settingname'] = 'settingvalue'; // for core settings
</code>

These defaults are used during install, upgrade and are also displayed as defaults on Site administration pages.

== Reset user password ==

If you happen to forget your admin password (or you want to set a password for any other user on the site), you can use reset_password.php script. The script sets the correctly salted password for the given user.

$ sudo -u apache /usr/bin/php admin/cli/reset_password.php

== MySQL storage engine conversion ==

If you run your Moodle site with MySQL database backend and use the default MyISAM as the storage engine for your tables, you may want to convert them to use some more reliable engine like InnoDB (actually, you should want to switch to PostgreSQL ;-) anyway).

$ sudo -u apache /usr/bin/php admin/cli/mysql_engine.php --engine=InnoDB

==Converting InnoDB tables to Barracuda==

Sites using MySQL with database tables using Antelope as the file format are recommended to convert the tables to the Barracuda file format.

This is because tables using Antelope as the file format cannot handle more than 10 text columns. This file formats only supports ''compact'' and ''redundant'' row formats for backward compatibility reasons. This may cause a problem on larger sites when restoring a course, in which case the following error will be displayed:

Row size too large (>8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help.

Barracuda is the newest innoDB file format. In addition to supporting ''compact'' and ''redundant'' row formats, Barracuda also supports ''compressed'' and ''dynamic'' row formats.

However, converting tables to Barracuda is only recommended, and not required, since not all MySQL users are affected. (It may only be a problem for larger sites.)

===Tool for converting tables===

A command line tool is included in Moodle for converting tables to Barracuda.

To view tables requiring conversion, use the list option:

$ php admin/cli/mysql_compressed_rows.php --list

Here is an example output:

mdl_data Compact (needs fixing)
mdl_data_fields Compact (needs fixing)
mdl_enrol_paypal Compact (needs fixing)

To proceed with the conversion, run the command using the fix option:

$ php admin/cli/mysql_compressed_rows.php --fix

Successful table conversion will be reported in the output, for example:

mdl_data ... Compressed
mdl_data_fields ... Compressed
mdl_enrol_paypal ... Compressed

Please note that the commands must be executed on your moodle directory. Once tables are fixed, the warning message will no longer be displayed.

For further information on InnoDB file formats see the [http://dev.mysql.com/doc/innodb/1.1/en/glossary.html#glos_antelope MySQL InnoDB glossary - Antelope] and the [http://dev.mysql.com/doc/innodb/1.1/en/glossary.html#glos_barracuda MySQL InnoDB glossary - Barracuda].

If you get errors due to having insufficient privileges to run these commands (this is quite likely) then the easiest solution is to generate the required SQL commands using,

$ php admin/cli/mysql_compressed_rows.php --showsql

You can then copy the generated SQL into your mysql client running as the 'root' user.

== Running cron via command line ==

In versions 1.x, you could execute admin/cron.php either from command line or via the web. Since Moodle 2.0, only admin/cli/cron.php script can be run via command line.

== Scheduled tasks ==

Scheduled tasks are automatically run by the cron script, but the specific tasks which run on each cron iteration are determined by the scheduled tasks configuration. It is possible to override the scheduled tasks configuration and run a single scheduled task immediately using the admin/tool/task/cli/schedule_task.php script.

This script accepts the following arguments:

--list - list all the known scheduled tasks. The tasks are listed by the class name used to run the task. This class name is required as the argument to the next option in order to run a specific task immediately.

--execute=<task> - Runs a single scheduled task immediately - regardless of scheduling settings. This will even run disabled tasks. Tasks will still use locking to prevent concurrent execution of the same task - even on clusters. The format of the <task> argument must be the same as returned by the --list option above.

'''Note:''' You must escape the "\" with an extra \ when using the --execute command. Take the following for example:

<pre>php schedule_task.php --list</pre>

will return something like:

<pre>
== List of scheduled tasks (http://yourserver.com/moodle) ==
\enrol_imsenterprise\task\cron_task 10 * * * * * ASAP
\logstore_legacy\task\cleanup_task * 5 * * * * ASAP
\logstore_standard\task\cleanup_task * 4 * * * * Wednesday, November 12, 2014, 4:35 AM
\mod_forum\task\cron_task * * * * * * ASAP
\core\task\automated_backup_task 50 * * * * * ASAP

...
</pre>

To run the first task in that list, you would execute

<pre>php schedule_task.php --execute=\\enrol_imsenterprise\\task\\cron_task</pre>

==Database transfer==

A command line script for [[Database transfer]] may be found in ''admin/tool/dbtransfer/cli/migrate.php''.

==Purge caches==

You can purge caches using this script:

php admin/cli/purge_caches.php

==Fix course / module sequences==

In rare cases (such as after upgrading from a very old version of Moodle), the course / section / module sequence data can be out of sync. This can cause various problems for affected courses, such as sections not appearing, backups failing, pages not displaying etc. There is a specific check to check for errors caused by this problem, and to fix the data in the database if they are found. To run this script please use the command below:

php admin/cli/fix_course_sequence.php -c=* --fix

This will check every course in Moodle and report which ones had errors and were fixed.

==Fix orphaned question categories==

When a quiz is created, a new question category for the quiz is automatically created. In versions of Moodle prior to 2.9.1, if the quiz is deleted, the question category and any questions in the category remain in database. These orphaned question categories may be fixed by running the admin/cli/fix_orphaned_question_categories.php script with the --fix option.

==Search and replace text==

This script can be used to search and replace text throughout the whole database. Use carefully and backup first always. More info in [[Search and replace tool]].

php admin/tool/replace/cli/replace.php --search=//oldsitehost --replace=//newsitehost

==See also==

* MDL-35736 - Manage plugins via command line
* MDL-36237 - Resort course list via CLI
* [http://moosh-online.com/ MOOSH] - MOOdle SHell. It is a commandline tool that will allow you to perform most common Moodle tasks.

[[fr:Administration en ligne de commande]]
[[de:Administration über Kommandozeile]]
[[ja:コマンドライン経由の管理]]
[[es:Administración por línea de comando]]

Universal Office Converter (unoconv)

2016-05-19T08:55:01Z

Howardsmiller: /* Installing unoconv on Linux */

=Installing unoconv=

"unoconv" is a command line program that is used to convert between different office document file formats. It uses an instance of [http://libreoffice.org LibreOffice] to do the conversion and is used by the assignment module to convert documents to pdf so that they can be annotated. If unoconv is not installed - the only impact is that the assignment module will only allow annotations when students upload a pdf document.

The steps required to install unoconv are different depending on the operating system that you have installed Moodle on.

== Installing unoconv on Linux ==
The required version of unoconv is at least 0.7. Depending on your flavour of linux, this may be available in your package manager and you can install it directly with:

(Ubuntu 16.04 LTS)

<pre>
apt-get install unoconv
</pre>

If your package manager contains an older version of the package, you will have to find a newer version and install it manually ([https://packages.debian.org/stretch/unoconv Debian Testing]). Unoconv itself is just a python script, so it has few dependencies.

Potential problems:
* On some systems the apache user home directory is set to a non existent folder. This can cause unoconv to fail. There are 2 solutions to this - one is to make a (writable) home directory for the apache user (like /home/www-data). The other is to run a unoconv listener (described below) as another user other than the apache user (someone with a valid, writable home directory).
* If you are still running 14.04LTS then unoconv won't work as shipped. This might not be the most efficient route but it worked by first installing unoconv (version 0.6) from the package manager as above. You will then need to grab unoconv 0.7 from Github (https://github.com/dagwieers/unoconv), then upgrade to the latest libreoffice using the PPA (https://launchpad.net/~libreoffice/+archive/ubuntu/ppa). Point moodle at the Github version of unoconv. You need to modify the Python unoconv file by changing 'python' in the first line to 'python3'. You also need to change the permissions on the directory /var/www so that the user www-data can write to it (www-data needs to write to its home directory which it cannot do by default).

== Installing unoconv on OS X ==
Download and install LibreOffice for Mac. Make sure to run it and verify it is working before continuing.

Get the latest version of the unoconv python script. One way to do this is with [[http://brew.sh/ brew]].
<pre>
brew install unoconv
</pre>

If you haven't done it already - install ghostscript. One way to install ghostscript is also with [[http://brew.sh/ brew]]
<pre>
brew install ghostscript
</pre>

Set the paths to unoconv and ghostscript in Moodle (Site administration ▶︎ Server ▶︎ System paths ). If you used brew, they will both be installed to /usr/local/bin.

== Installing unoconv on Windows ==
Download and install LibreOffice for windows.

Download the latest version of the unoconv script from https://github.com/dagwieers/unoconv/releases.

Rename the downloaded script to C:\unoconv\unoconv.py

Create a batch file C:\unoconv\unoconv.bat with these contents:

<pre>
@cd "C:\Program Files (x86)\LibreOffice 5\program"
@"python-core-3.3.0\bin\python.exe" unoconv.py %*
</pre>

Set paths in Moodle.

Login as admin and go to Site administration ► Server ► System paths

Set pathtogs setting to your ghostscript installation binary, (C:\gs\bin\gswin32.exe)

Set pathtounoconv to the batch file created above (C:\unoconv\unoconv.bat)

Test ghostscript and unoconv are working correctly in the admin test pages "Site administration ► Plugins ► Activity modules ► Assignment ► Feedback plugins ► Annotate PDF".

== Run a unoconv listener ==
unoconv utilises a client/server process when converting documents. By default, when there is no running server process - each time unoconv runs it will start a server process, send it's request and shutdown the server process when the request is complete. The drawback of this mode is that if 2 requests are submitted simultaneously - this can cause the first request to shutdown the server process when the second request is still in progress - and the second conversion request fails. A more robust way to configure unoconv is to start a server process at boot time, and run a script to monitor it and restart it if it crashes.

To start a unoconv listener at boot time on linux - you need a start up script. Different linux distributions use different startup scripts - but here is an example of an init.d script for debian systems.

[[mod/assign/feedback/editpdf/testunoconv/initd | Init script for Debian]]

== Offload processing to a different server ==
Processing office documents can put increased load on your webserver, which may impact on the responsiveness of your site. If you are installing unoconv on a large site you may want to consider running unoconv on a server that is not also serving web requests.

How to do this:

Install unoconv on each webservers and the remote server following the installation instructions above.

Make sure unoconv is started at boot time on the remote server with the "--listener" argument and is monitored and restarted if it exits (see Debian init script for an example of how to do this).

Open the firewall port 2002 between the moodle webservers and the machine running unoconv.

Share the moodle data root between the webservers and the machine running unoconv. This folder must be mounted at the same path on all servers.

Install a wrapper for unoconv on the webservers that forwards the requests to the remote server. Example:
<pre>
#!/bin/bash
# Wrapper script for unoconv to forward processing.
# Install to /usr/bin/unoconv-remote with 755 permissions
/usr/bin/unoconv --server=<ip of remote server> "$@"
</pre>

Configure the path to unoconv in the Moodle admin settings to point to this wrapper script.

==Additional Resources==
The unoconv [https://github.com/dagwieers/unoconv documentation] site has additional information on installation of unoconv and troubleshooting tips.

[[Category:Site administration]]
{{Installing_Moodle}}

[[es:mod/assign/feedback/editpdf/testunoconv]]

Universal Office Converter (unoconv)

2016-05-19T08:53:01Z

Howardsmiller: /* Installing unoconv on Linux */

=Installing unoconv=

"unoconv" is a command line program that is used to convert between different office document file formats. It uses an instance of [http://libreoffice.org LibreOffice] to do the conversion and is used by the assignment module to convert documents to pdf so that they can be annotated. If unoconv is not installed - the only impact is that the assignment module will only allow annotations when students upload a pdf document.

The steps required to install unoconv are different depending on the operating system that you have installed Moodle on.

== Installing unoconv on Linux ==
The required version of unoconv is at least 0.7. Depending on your flavour of linux, this may be available in your package manager and you can install it directly with:

(Ubuntu 16.04 LTS)

<pre>
apt-get install unoconv
</pre>

If your package manager contains an older version of the package, you will have to find a newer version and install it manually ([https://packages.debian.org/stretch/unoconv Debian Testing]). Unoconv itself is just a python script, so it has few dependencies.

Potential problems:
* On some systems the apache user home directory is set to a non existent folder. This can cause unoconv to fail. There are 2 solutions to this - one is to make a (writable) home directory for the apache user (like /home/www-data). The other is to run a unoconv listener (described below) as another user other than the apache user (someone with a valid, writable home directory).
* If you are still running 14.04LTS then unoconv won't work as shipped. This might not be the most efficient route but it worked by installing unoconv from the package manager as above. You will need to grab unoconv 0.7 from Github (https://github.com/dagwieers/unoconv), then upgrade to the latest libreoffice using the PPA (https://launchpad.net/~libreoffice/+archive/ubuntu/ppa). Point moodle at the Github version of unoconv. You need to modify the Python unoconv file by changing 'python' in the first line to 'python3'. You also need to change the permissions on the directory /var/www so that the user www-data can write to it (www-data needs to write to its home directory which it cannot do by default).

== Installing unoconv on OS X ==
Download and install LibreOffice for Mac. Make sure to run it and verify it is working before continuing.

Get the latest version of the unoconv python script. One way to do this is with [[http://brew.sh/ brew]].
<pre>
brew install unoconv
</pre>

If you haven't done it already - install ghostscript. One way to install ghostscript is also with [[http://brew.sh/ brew]]
<pre>
brew install ghostscript
</pre>

Set the paths to unoconv and ghostscript in Moodle (Site administration ▶︎ Server ▶︎ System paths ). If you used brew, they will both be installed to /usr/local/bin.

== Installing unoconv on Windows ==
Download and install LibreOffice for windows.

Download the latest version of the unoconv script from https://github.com/dagwieers/unoconv/releases.

Rename the downloaded script to C:\unoconv\unoconv.py

Create a batch file C:\unoconv\unoconv.bat with these contents:

<pre>
@cd "C:\Program Files (x86)\LibreOffice 5\program"
@"python-core-3.3.0\bin\python.exe" unoconv.py %*
</pre>

Set paths in Moodle.

Login as admin and go to Site administration ► Server ► System paths

Set pathtogs setting to your ghostscript installation binary, (C:\gs\bin\gswin32.exe)

Set pathtounoconv to the batch file created above (C:\unoconv\unoconv.bat)

Test ghostscript and unoconv are working correctly in the admin test pages "Site administration ► Plugins ► Activity modules ► Assignment ► Feedback plugins ► Annotate PDF".

== Run a unoconv listener ==
unoconv utilises a client/server process when converting documents. By default, when there is no running server process - each time unoconv runs it will start a server process, send it's request and shutdown the server process when the request is complete. The drawback of this mode is that if 2 requests are submitted simultaneously - this can cause the first request to shutdown the server process when the second request is still in progress - and the second conversion request fails. A more robust way to configure unoconv is to start a server process at boot time, and run a script to monitor it and restart it if it crashes.

To start a unoconv listener at boot time on linux - you need a start up script. Different linux distributions use different startup scripts - but here is an example of an init.d script for debian systems.

[[mod/assign/feedback/editpdf/testunoconv/initd | Init script for Debian]]

== Offload processing to a different server ==
Processing office documents can put increased load on your webserver, which may impact on the responsiveness of your site. If you are installing unoconv on a large site you may want to consider running unoconv on a server that is not also serving web requests.

How to do this:

Install unoconv on each webservers and the remote server following the installation instructions above.

Make sure unoconv is started at boot time on the remote server with the "--listener" argument and is monitored and restarted if it exits (see Debian init script for an example of how to do this).

Open the firewall port 2002 between the moodle webservers and the machine running unoconv.

Share the moodle data root between the webservers and the machine running unoconv. This folder must be mounted at the same path on all servers.

Install a wrapper for unoconv on the webservers that forwards the requests to the remote server. Example:
<pre>
#!/bin/bash
# Wrapper script for unoconv to forward processing.
# Install to /usr/bin/unoconv-remote with 755 permissions
/usr/bin/unoconv --server=<ip of remote server> "$@"
</pre>

Configure the path to unoconv in the Moodle admin settings to point to this wrapper script.

==Additional Resources==
The unoconv [https://github.com/dagwieers/unoconv documentation] site has additional information on installation of unoconv and troubleshooting tips.

[[Category:Site administration]]
{{Installing_Moodle}}

[[es:mod/assign/feedback/editpdf/testunoconv]]

Cron

2015-08-10T11:57:28Z

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

A special program (typically called - not surprisingly - 'cron') is used to run the Moodle cron script at a regular interval. The Moodle cron script runs tasks include sending mail, updating Moodle reports, RSS feeds, activity completions, posting forum messages and other tasks. Since different tasks have different schedules, not every task will run in Moodle when the cron script is triggered.

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.'''
# The web based script. 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===
* As of Moodle 2.9, 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==
* [http://www.coursebit.net/moodle-cron-job/ All About the Moodle Cron Job]
* [https://docs.moodle.org/37/en/Scheduled_tasks Scheduled tasks Moodle docs]
* [http://en.wikipedia.org/wiki/Cron Wikipedia article on cron function]

Using Moodle forum discussions:
*[http://moodle.org/mod/forum/discuss.php?d=41827 Cron - can someone give me a quick confirmation of function?]
*[http://moodle.org/mod/forum/discuss.php?d=97684 Cronjob Question]
*[http://moodle.org/mod/forum/discuss.php?d=97457 Slow cron : avoiding simultaneous cron]
*[http://moodle.org/mod/forum/discuss.php?d=117168 Visibility of cron.php]
*[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.

[[es:Cron]]
[[fr:Cron]]
[[ja:Cron]]
[[de:Cron-Job]]

Video

2015-08-10T10:48:26Z

Howardsmiller: /* See also */

{{Working with media}}
*Video is a very powerful tool to use in a Moodle course, allowing students, for example to catch up on lectures they missed, learn from a "how to" screencast, or improve their language skills by watching native speakers interact.
*For a discussion on the best type of video file for Moodle, see [http://moodle.org/mod/forum/discuss.php?d=143478| here]
''
*For a discussion of the best programs for creating screencasts, see [http://moodle.org/mod/forum/discuss.php?d=147891| here]

==Where to host the videos==

*Whenever possible, it is preferable to upload your videos to Moodle, storing them on your own server as you retain ultimate control. However, when server space or upload limits are restricted, it is convenient to upload videos to an online site like youtube [http://www.youtube.com] or Vimeo[http://vimeo.com]. They can easily be embedded inside Moodle from such sites and privacy can still be maintained if you choose their private video sharing option.

===Cross domain video hosting===

Flash video players require permission to play videos hosted on a different URL, e.g. yourmoodle.org needs permission to play video files hosted at yourvideo.org. The permission files are stored on the root domain of where the video files are hosted, e.g. yourvideos.org/crossdomain.xml. If yourvideos.org does not have a cross domain policy file that permits yourmoodle.org to play videos, Flash Player will not permit it. Further details are available here [http://code.google.com/p/moodle-mplayer/wiki/CrossDomainSecurity].

Many public video hosting services, such as YouTube.com, already have catch-all cross domain policy files in place and so videos can be played from them via your Moodle without any cross domain security issues arising.

==Ways of displaying video==

===Linking to a video online elsewhere===
*If your video is hosted elsewhere online (such as youtube) you can simply link to the relevant page by choosing ''Add a resource>[[URL|URL]]'' and pasting in the relevant link.
*For more information, see [[URL|URL]]
*Note that, in an establishment where certain video sharing sites might be banned, your students might not be able to access your video through Moodle.

===Uploading a video for students to download===
*Choose this option if you wish to upload your video to Moodle and give users the option to download it to their own computers.
*Choose ''Add an activity or resource>[[File|File]]''
*For more information, see [[File|File]]
*Note that the way the video will display depends on the software the user has on their own computer. This could mean that some students might be unable to view your video. (See this discussion [http://moodle.org/mod/forum/discuss.php?d=143478| here])

===Embedding a video in its own player===
*Moodle has an inbuilt video player called Flowplayer. If the [[Multimedia plugins filter|multimedia plugins filter]] is enabled by the administrator, videos embedded into the text editor will play inline in Flowplayer.
*Anywhere that Moodle's text editor is available, it is possible to embed a video, for example in a [[Label|label]] or a [[Page|page]], a course topic summary, a [[Description_question_type| quiz description]] or a [[Lesson|lesson]].
*One exception seems to be MP4 files. They don't seem to play in Flowplayer unless hacked. See discussion here: http://moodle.org/mod/forum/discuss.php?d=208849

====Using the Moodle media icon====
*With your editing turned on, click into the HTML editor where you wish to embed your video.
*Click the Moodle media icon as in the following screenshot:
[[File:Addmedia.png]]
*Click ''Browse repositories''

[[File:attomediaupload.png]]

*The file picker will appear:
[[File:Filepickermedia.png]]
*Either click ''Upload a file'' to upload from your computer or choose the appropriate repository from which you wish to bring in your video. (What you see will depend on what the Moodle admin has enabled)
*Note: '''To search for and embed a video from youtube, [[Youtube_videos|see here]]'''
*Change the ''save as/author/license'' settings if desired and click ''upload this file'' or ''select this file''
*Your video will appear in a preview player. Click ''Insert'' at the bottom
*'''''Don't panic''!''' You will now only get a blue text link of your video:
[[File:Moodletvgirlpreview.png]]
*When you click ''save changes'' to return to the main course page, your video will display:
[[File:Moodletvgirl2.png]]

====Using a hyperlink====
(Note - this method has no advantage over using the media icon, but was popular in older versions of Moodle)
*With your editing turned on, click into the HTML editor where you wish to embed your video.
*Type some blank spaces (or some text) and select them.
*Click the hyperlink icon as in the following screenshot.(The icon will only be clickable if you have selected text or spaces)
[[File:Hyperlinkicon.png]]
*Click 'Browse repositories'
*This takes you to the file picker. Follow the instructions for uploading/selecting your video as for using the Moodle media icon.
*When your video is chosen, it will appear in the link URL box as below. Click ''Insert:''
*'''''Don't panic!''''' You will now only get a blue line (if you selected blank spaces) or the actual text underlined in the HTML editor:
[[File:linklinkatto.png]]
*When you click ''save changes'' to return to the main course page, your video will display.

====Using embed code to display external videos====
*Go to your chosen video sharing site and find the embed code of the video you wish to display. Copy this code.
*With your editing turned on, click into the HTML editor where you wish to embed your video.
*Click the HTML code icon as in the following screenshot:
[[File:Htmlcodeicon.png]]
*Paste your embed code into the box:
[[File:Embedcode.png]]
*Scroll down and click "update".
*Your video will be previewed in the HTML editor. Click ''save changes'' for it to display on the page
[[File:Youtubevideo.png]]

==See also==
*[[Video_FAQ|Video FAQ]]
*[[Multimedia plugins filter]]
*[http://www.mguhlin.org/2012/01/embedding-videos-in-moodle-22.html Embedding Videos in #Moodle 2.2] blog post from Miguel Guhlin
*[[Videofile]] plugin with multilanguage captions capability
*[https://moodle.org/mod/forum/discuss.php?d=317841 Moodle.org forum discussion about players and encoding]

[[de:Video]]
[[es:Video]]

Upload courses

2014-08-24T09:35:32Z

Howardsmiller: /* Course information fields */

{{Courses}}
An administrator can upload multiple courses via text file in ''Administration > Site administration > Courses > Upload courses''.

In addition to creating new courses, this functionality may also be used to update or delete courses, or import content from another course. For information on using this functionality to create course templates, see [[Adding a new course]]

==Upload courses==

To upload one or more courses

# Go to ''Administration > Site administration > Courses > Upload courses''
# Either drag and drop the CSV file or click the 'Choose a file' button and select the file in the file picker
# Select appropriate import options carefully, then click the preview button.

{|
|[[File:26uploadcourses.png|250px|thumb|Upload courses admin screen]]
|
|[[File:uploadcoursesresults.png|250px|thumb|Courses successfully uploaded]]
|}

Note: It is also possible to use the command-line tool ''admin/tool/uploadcourse/cli/uploadcourse.php''.

When using the web interface, use the ''Preview'' option to see if any errors were detected in the previewed rows. If you proceed with the upload and there were something wrong detected with a course, it will be ignored.

=== Short file example ===
uploadcourse.csv:

Note: shortname, fullname, and category are required.

The category field takes the id of the category, with the default category Miscellaneous having id 1. Categories must already exist. If you put a category id that does not exist, you will receive a "Could not resolve category by ID" error during upload preview, and courses in that category will not be created.

<code bash>
shortname,fullname,category,summary,enrolment_1,enrolment_1_role,enrolment_1_enrolperiod,role_student
courserestored,Course restored,1,a summary,manual,student,1 month,
courserestored2,Course restored 2,1,a summary,,,,
courserestored3,Course restored 3,1,a summary,,,,padawan
courserestored4,Course restored 4,1,"a summary, with comma",manual,student,1 month,padawan
</code>
Notice there are no spaces between the items.

==Creating the text file==

The text file to upload courses must be a CSV file. It accepts the following columns which are divided in two categories, the course information, and the course actions.

===Course information fields===

Most of those settings are available on the settings page of a course. Please refer to [[Course settings]] for more information. Field names must be lower-case.

;shortname
: The shortname
;fullname
: The full name
;idnumber
: The ID number
;category
: The ID of the category to place the course in. This takes precedence over ''category_idnumber'' and ''category_path''.
;category_idnumber
: The ID number of the category to place the course in. This takes precedence over ''category_path''.
;category_path
: The path of the category to place the course in. If you want to place the course in a category named "Science-Fiction" which is located under the category "Movies", the value to provide is: <code>Movies / Science-Fiction</code>. Note that the separator must be <code>[space]/[space]</code>. Also note that the category MUST exist, it will not be created. If you want to place the course in the top-level category "Movies", the value to provide is: <code>Movies</code>
;visible
: 1 if the course is visible, 0 if hidden
;startdate
: The time at which the course starts. Please note that this value is passed to the PHP function [http://php.net/manual/en/function.strtotime.php strtotime] to generate a timestamp. Example 01.12.2014 (1st December 2014)
;summary
: The summary of the course
;format
: The course format to use, this must be a valid course format plugin name. E.g. ''weeks'', ''topics''.
;theme
: The theme to use
;lang
: The language to use
;newsitems
: The number of news items
;showgrades
: 1 to show the gradebook to students, 0 to hide it.
;showreports
: 1 to show the activity reports, 0 to hide it.
;legacyfiles
: 1 to enable the legacy course files, 0 not to.
;maxbytes
: The maximum upload size of the course in bytes. Use 0 for the site limit.
;groupmode
: 0 for ''No groups'', 1 for ''Separate groups'' and 2 for ''Visible groups''.
;groupmodeforce
: 1 to force the group mode, otherwise enter 0.
;enablecompletion
: 1 to enable the activity completion, 0 not to.

====Enrolment fields====

Some fields can be constructed to enable and configure enrolment methods. The fields must be named ''enrolment_[number]'' for the enrolment method name, and ''enrolment_[number]_property'' for its properties.

;enrolment_[number]
: The name of the enrolment method
;enrolment_[number]_delete
: 1 to delete this enrolment method from the course, if set to 1 all the other properties will be ignored.
;enrolment_[number]_disable
: 1 to disable this enrolment method from the course, if set to 1 all the other properties will be ignored.
;enrolment_[number]_startdate
: The enrolment start date. This value is passed to the PHP function strtotime().
;enrolment_[number]_enddate
: The enrolment end date. This value is passed to the PHP function strtotime().
;enrolment_[number]_enrolperiod
: Number of seconds, or if not a value understood by strtotime() such as "4 days".
;enrolment_[number]_role
: The role short name
;enrolment_[number]_[property]
: Where property is understood by the specified enrolment method
;enrolment_[number]_password
: The course enrolment key

Note: Upload courses is not yet compatible with all [[Enrolments|enrolment methods]] (MDL-43127).

'''Example'''

enrolment_1: manual
enrolment_1_role: student
enrolment_1_enrolperiod: 1 month

enrolment_2: self
enrolment_2_startdate: 2013-01-30

====Role renaming====

To rename some roles, using the following pattern:

;role_[shortname]
: The new name of the role ''[shortname]''.

'''Example'''

role_student: Apprentice
role_teacher: Master
role_mycustomrole: Jedi

It is worth noting that the short name for the teacher role is ''editingteacher'' and the short name for the non-editing teacher is ''teacher''.

===Course action fields===

Those settings take precedence over the ''Course process'' parameters.

;delete
: 1 to delete the course
;rename
: The shortname to rename the course to
;backupfile
: An absolute path to a backup file (.mbz) to import in the course
;templatecourse
: The short name of a course to import the content from
;reset
: 1 to reset the course

===Mandatory fields===

;shortname
: This field is mandatory for every operation, with the only exception of creating new courses. See details on the course process parameter ''Shortname template'' for more information.
;fullname
: Required when creating a new course.
;category, category_idnumber, category_path
: One of these is required when creating a course.

===Import options===

To prevent unexpected behaviour, you have to specify what you want the tool to be able to do.

;Upload mode
: This allows you to specify if courses can be created and/or updated.
;Update mode
: If you allow courses to be updated, you also have to tell the tool what to update the courses with.
;Allow deletes
: Whether the ''delete'' field is accepted or not
;Allow renames
: Whether the ''rename'' field is accepted or not
;Allow resets
: Whether the ''reset'' field is accepted or not

===Course process===

This allows you to specify actions to be taken for every course uploaded.

;Shortname template
: If you are creating courses without a shortname, you can use this field to automatically generate a shortname. This field accepts two placeholders: %i for the ID number, %f for the summary.
;Restore file
: A backup file (.mbz) to import in the course after create/update.
;Restore from course
: The shortname of a course to import content from after create/update.
;Reset after upload
: Whether to reset the course after creating/updating it.

===Default course values===

Those are values that can be set in the web interface for all the fields that are not specified in the CSV file. Note that they are always used when creating a course, but only when specified during update (see ''Update mode'').

==Increasing speed==

When importing the content of a backup file, or another course, you are advised to enable the setting ''keeptempdirectoriesonbackup''. This will considerably speed up the process of the upload if you are importing multiple times from the same source.

==See also==

* Demo screencast: [http://youtu.be/MzK2jb-9SwE Bulk course creation]
* [[Upload users]]
* [http://www.moodleblog.net/2013/11/24/creating-course-templates-in-moodle-2-6/ Creating course templates in Moodle 2.6] blog post by Mary Cooch

[[de:Kurse hochladen]]
[[es:Subir cursos]]

Caching

2014-06-10T08:30:10Z

Howardsmiller: typo

{{Performance}}

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

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

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

==General approach to performance testing==

Here is the general strategy you should be taking:

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

==Cache configuration in Moodle==

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

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

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

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

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

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

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

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

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

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

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

===Cache stores===
Cache stores are a plugin type within Moodle. They facilitate connecting Moodle to the cache backends discussed above. 
Moodle ships with the three defaults mentioned above as well as Memcache, Memcached, and MongoDB. 
You can find other cache store plugins in the [https://moodle.org/plugins/browse.php?list=category&id=48 plugins database]. 
The code for these is located within cache/stores in your Moodle directory root.

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

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

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

===How it ties together===

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

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

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

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

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

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

===Locking===

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

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

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

===Sharing===

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

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

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

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

As an example if you had several Moodle sites all the same version running on server with APC installed you could decide to map the language cache to the APC store and configure sharing for all sites running the same version. 
The language cache for sites on the same version is safe to share, it is used on practically every page, and APC is extremely fast. These three points may result in a nice wee performance boost for your sites.

==The cache configuration screen==

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

===Accessing the cache configuration screen===

[[Image:caching-27-01-configuration-screen.png|thumb|500px|The cache configuration screen in Moodle 2.6]]

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

===Installed cache stores===

[[Image:caching-27-02-installed-cache-stores.png|thumb|500px|Installed cache stores screenshot]]

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

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

===Configured store instances===

[[Image:caching-27-03-configured-store-instances.png|thumb|500px|Configured store instances screenshot]]

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

; '''Store name''' : The name given to this cache store instance when it is created so that you can recognise it. It can be anything you want and is only used so that you can identify the store instance.
; '''Plugin''' : The cache store plugin of which this is an instance of.
; '''Ready''' : A tick gets shown when all PHP requirements have been met as well as any connection or set-up requirements have been verified.
; '''Store mappings''' : The number of caches this store instance has been mapped to explicitly. Does not include any uses through default mappings (discussed below).
; '''Modes''' : The modes that this cache store instance can serve.
; '''Supports''' : ''Advanced''. The features supported by this cache store instance.
; '''Locking mechanism''' : ''Advanced''. The locking mechanism this cache store instance will make use of. We've not discussed this yet, but read on and you'll find information on it.
; '''Actions''' : Any actions that can be performed against this cache store instance.

===Known cache definitions===

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

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

For each cache shown here you get the following information:

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

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

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

===Summary of cache lock instances===

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

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

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

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

This table quickly shows which cache store instances are going to be used for cache types if there are specific mappings in place. 
Of simply this shows the default cache store instances.

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

==Adding cache store instances==

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

===File cache===

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

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

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

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

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

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

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

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

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

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

===Memcache===

[[Image:caching-27-08-add-memcache-store.png|thumb|300px|Add Memcache store screenshot]]

Before you can add a Memcache store instance you must first have a Memcached server you can access and have the Memcache php extension installed and enabled on your web server.

Like the file store you must provide a the store name. It is used to identify the store instance in the configuration interface and must be unique to the site. 
For a Memcache store you must also enter the Memcache server, or servers you wish it to make use of.
Servers should be added one per line and each line can contain 1 to 3 properties separated by colons.
# The URL or IP address of the server (required)
# The port the server is listening on (optional)
# The weight to give this server (optional)

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

Optionally you can also specify a key prefix to use. What you enter here will prefixed to all keys before accessing the server and can be used to effectively partition the Memcache space in a recognisable way. This can be handy if you have a management tool for you Memcached server that you use to inspect what is stored there.

===Memcached===

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

Like the Memcache store you must first have a Memcached server you can access and have the Memcached php extension installed and enabled on your server.

Also like the Memcache store there are two required parameters in configuring a Memcached store.

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

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

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

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

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

===MongoDB===

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

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

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

==Mapping a cache to a store instance==

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

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

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

The screen you are presented allows you to map one or more cache store instances to be used by this cache.

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

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

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

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

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

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

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

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

Just a couple more points of interest:

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

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

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

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

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

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

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

==Configuring caching for your site==

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

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

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

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

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

==Other performance testing==

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

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

==Other performance advice for load-balanced web servers==

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

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

Cache related forum discussions that may help in understanding MUC:
* [https://moodle.org/mod/forum/discuss.php?d=217195 MUC is here, now what?]
* [https://moodle.org/mod/forum/discuss.php?d=226123 Status of MUC?]
* [https://moodle.org/mod/forum/discuss.php?d=222250 Putting cachedir on local disks in cluster]
* [https://moodle.org/mod/forum/discuss.php?d=232122 moodle cachestore_file]

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

[[de:Caching]]
[[es:Cacheando]]

Using Database

2014-03-06T13:10:21Z

Howardsmiller: /* Importing many entries */

{{Database}}
==Views==

===View list===

The list view shows multiple entries, possibly in a more abbreviated form to ensure all the information fits. You may use the controls at the bottom of the screen to search and sort the contents.

* ''View single'': one item at a time
* ''View list'' : several items at a time (number is user defined)
* ''Add entry'' : add an item to the database
* ''Search'' : search the entries

[[Image:26databaseview.png]]

=== View single ===

Alternatively, you may view only one entry at a time. This might allow you to view more detailed information than the list view.

=== Add comment ===

If comments have been enabled, you may add a comment.

=== Rate entries ===

If ratings have been enabled, and made viewable, by the database editor, you may [[Grades|grade]] other database entries, and view these ratings.

==Adding an entry==

Go to the "Add entry" tab and fill in the form.
===Deleting multiple entries===
{{New features}}
In List view, a checkbox will appear next to each entry. Select the entries you wish to delete and click the 'Delete selected' button. Alternatively, click the 'Select all' and the 'Delete all' buttons to delete all entries. A warning message will appear asking you to verify what you wish to delete.

==Automatically linking database entries==

If the [[Database auto-linking filter]] is enabled, any entries in a database will be automatically linked to where the concept words and/or phrases appear within the same course. This includes forum postings, internal resources, week summaries etc.

Note: If you do not want particular text to be linked (in a forum posting, say) then you should add <nolink> and </nolink> tags around the text. Alternatively the filter can be disabled for a particular activity.
==Approving and undoing approval of entries==

If, during database set up, 'Approval required' was set to 'Yes' then a teacher can approve an entry by clicking on the tick/checkmark icon.

Once an entry has been approved, it is possible to undo the approval by clicking the circle with a line through it icon. {{New features}}

{|
|[[File:26databaseapprove.png|thumb|Entry approved]]
|[[File:26databaseunapprove.png|thumb|Approval undone]]
|}

==Importing many entries==
You can import entries via a CSV file if you click the "Import entries" link under 'Database activity administration' in the Settings block. CSV means Comma-Separated-Values and is a common format for text interchange.

[[image:Databaseupload.png]]

The easiest way to determine the format of the text file is to manually add an entry to the database and then export it. The resulting export text file may then be edited and used for importing entries. Here's a sample of what a very simple file will look like.

[[Image:Upload_csv_sample.png]]

The expected file format is a plain text file with a list of field names as the first record. The data then follows, one record per line.

The field delimiter defaults to a comma character and the field enclosure is not set by default (field enclosures are characters that surround each field in each record).

Records should be delimited by new lines (usually generated by pressing RETURN or ENTER in your text editor). Tabs can be specified using \t and newlines by \n.

Sample file:

name,height,weight
Kai,180cm,80kg
Kim,170cm,60kg
Koo,190cm,20kg

Note: Certain field types may not be supported.

Do not put spaces after your commas or upload will fail!

After upload page import.php comes back blank if it failed.
If successful you'll read a message like, "1 entries saved".

==Exporting entries==

You can export entries either in CSV (comma separated values) or ODS (OpenOffice Calc) formats by clicking the tab at the top or by clicking the "Export entries" link under 'Database activity administration' in the Settings block. (Both CSV and ODS formats can be opened with MS Excel.)

[[File:Databasexport.png]]

When using the CSV format, the user can select either the comma, semicolon, or tab to separate the fields. The selection of the proper character is important. If users select to use a comma to separate the fields and some of the fields contain data with commas then the number of columns is going to be misaligned and likely cause confusion.

Users can select which fields from the database they wish to have exported. By default, all fields are checked to be included. Choose the fields that you wish to have included in the export.

Once the export type and the fields to be exported have been selected, clicking on the Export entries pushbutton will generate the file. The user will usually have the option of either opening or saving the file.

For information on converting the date export (and import) format, see the discussion [https://moodle.org/mod/forum/discuss.php?d=220505 Standard Database Module - Dates].

==Exporting to an external portfolio==

If an external [[Portfolios|portfolio]] such as [[Mahara_portfolio|Mahara]] has been enabled by the administrator then users have the option to export individual entries to that portfolio. They will see at the bottom of a database entry an "export" icon to click on and select the portfolio to export to:

[[File:Exportdatabasentry.png]]

== Example databases ==

Moodle.org has two good examples of the database module in action:

* [http://moodle.org/mod/data/view.php?id=6140 Moodle Buzz], a database of the titles, authors and web links to news articles mentioning Moodle
* [http://moodle.org/mod/data/view.php?d=26 Themes], a database with screenshots, download links and user comments about Moodle [[Themes|themes]]

== Creative uses ==

You could use the database module to:

* allow collaboration on building a collection of web links/books/journal references related to a particular subject
* display student created photos/posters/websites/poems for peer comment and review
* gather comments and votes on a shortlist of potential logos/mascot names/project ideas
* provide a [http://moodle.org/mod/forum/discuss.php?d=52699 student file storage area]
* maintain a log of what was done in a face-to-face class each day, so that absent students can get caught up themselves. [http://moodle.org/mod/forum/discuss.php?d=115047 Example]

== See also ==

*[http://school.demo.moodle.net/course/view.php?id=127&section=3 Examples of databases in the School demo site] (available for download)
* [[Dataform module]], which is a major enhancement of the Database module with improved browsing, editing, searching and other features.
* [[Glossary module]], which performs a similar though more specialised, text-based role
* [[Using Moodle book]] Chapter 12: Databases
* Using Moodle [http://moodle.org/mod/forum/view.php?id=3505 Database activity module forum]
* [http://treadwell.cce.cornell.edu/moodle_doc/database_moodle/index.html Screencast introducing the Database Module and walking through creating a database]
* [http://moodle.org/mod/data/view.php?rid=2424 Tracking Students' Reading with the Moodle Database Module] presentation
Using Moodle forum discussions:
* [http://moodle.org/mod/forum/discuss.php?d=72260 Database Module: Each learner Private DB?]
* [http://moodle.org/mod/forum/discuss.php?d=84487 Database for Dummies please!]
* [http://moodle.org/mod/forum/discuss.php?d=89117 Restricting access to database content by user?]
* [http://moodle.org/mod/forum/discuss.php?d=139137 How to use the database activity module?]

[[de:Datenbank nutzen]]
[[es:Usando BasedeDatos]]