MoodleDocs - User contributions [en]

Windows installation

2008-01-19T22:53:42Z

Szymonk: added inter-language link to pl wiki

==Installation Packages==
If you are running a small (less than 30 users) Moodle server or just want to test Moodle on your Windows XP PC, pre-built packages are available for you to use. Here are links to pages containing step-by-step instructions for installing Moodle using install packages:

*[[Complete install packages]] for most Windows versions

*[[Installing_AMP#Windows| This section has a quick]] way to install a complete package on a Windows XP machine

*[[Windows installation using XAMPP|Installation guide for Windows using XAMPP]] in case you want to retrofit

*[[Installation guide for Windows using EasyPHP]]

*[[Installation guide - Moodle for Windows on a USB Memory Stick]]

== Manual Installation ==
For medium to large installations (e.g. a college, university or business), it is best practice to install Moodle on your server manually.

* '''Plan your system capacity'''. This involves estimating the appropriate hardware to support the number of users in your organisation. See [[Installing Moodle#How_many_users.3F| Installing Moodle ]] in the How Many Users section for a method of doing this.
* '''Install your database server'''. You have a choice of [http://dev.mysql.com/downloads/ MySQL] (recommended), [http://www.postgresql.org/download/ PostgreSQL], [[Installing MSSQL for PHP | Microsoft SQL Server 2005]] (only for Moodle 1.7 or later) or Oracle.
* '''Install PHP'''. See [http://www.peterguy.com/php/install_IIS6.html How to install PHP 5.x on Windows Server 2003 with IIS 6] for instructions.
* '''Install your web server'''. You have several choices - the decision as to which one to use will depend on your in-house expertise and your required level of sustainability:
**Apache 2 is recommended as the most tested and popular for Moodle installations. See these instructions for [[Installing Apache on Windows |manually installing Apache 2 on Windows]].
**IIS 6 can also be used. See the Windows forum for guidance on installation and, in particular, permission settings for using Moodle with IIS.
**Other webservers are known to install on Windows, e.g. Lighttpd, so you may wish to experiment with these if available memory is low on your server.
* '''Install Moodle''' by getting the standard installation for Moodle from [http://download.moodle.org/ http://download.moodle.org/] and read [[Installing Moodle]] which has detailed generic information.
* '''Setup backups'''. Once Moodle is setup and configured, you should setup backups of the system in case of failure or loss of data.
** '''To perform full site backups''' you need to backup the moodledata and moodle directories, Apache webserver configuration (httpd.conf) if you're using Apache, PHP configuration (php.ini) and any php extensions which are non-standard, and the mysql database. To do this use the integrated backup program (Start -> All Programs -> Accessories -> System Tools -> Backup) or your own proprietary backup software (e.g. BackupExec). To backup your mysql database see the [[Backup FAQ]].
** '''To perform course backups''' see the [[Course backup]] page.
** You should also perform a '''state backup''' of the [http://technet2.microsoft.com/WindowsServer/en/library/921f0ed5-523d-48ac-8825-e850b0e548841033.mspx?mfr=true server] or [http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/ntbackup_backup_sysstate.mspx?mfr=true PC]. This is especially important if you're using IIS as this will backup the IIS metabase.
* '''Check your server security and performance'''. It is also good practice to read the [[Performance]] and [[Security]] documentation. Although much of the content is targetted at Linux/Unix users, there is a growing amount for Windows systems.
* Set-up your '''Active Directory authentication'''. You can use the standard [[LDAP authentication]] which prompts users with a username/password, or [[NTLM authentication | integrated NTLM authentication]] which does not require campus users to enter their credentials.

== See also ==

* [http://moodle.org/mod/forum/view.php?id=6799 Windows-based server forum] is the main forum for asking questions about your Moodle Windows installation.
* [[Installing APC in Windows]] contains instructions for using a PHP accelerator to reduce processor load.
* [[Cron | Installing Cron on Windows]] for setting up the Moodle scheduled task.
* [[Configuring aspell on Windows 2003 Server]] for setting up the Moodle spell checker.
* [http://moodle.org/mod/forum/discuss.php?d=56835 Running Apache and IIS on the same server] forum discussion.
* [http://moodle.org/blog/index.php?userid=212926&courseid=55 A Windows installation log.]

[[Category:Administrator]]
[[Category:Installation]]

[[pl:Instalacja w Windows]]

Installing APC in Windows

2008-01-19T22:10:11Z

Szymonk: added inter-language link to pl wiki

== Introduction ==
APC (Alternative PHP Cache) is a PHP opcode cache. It stores PHP pages in RAM and reduces hard disk activity. This makes a real difference to the performance in Moodle, and you should be able to achieve a 50% increase in system capacity and your CPU will be 50% less busy.

This guide is for installation of APC on a Windows server. The instructions have been tested on a Windows 2003 server, and they should also be applicable if you are using Windows XP as a test server.

==Installation on Windows Server==
'''Warning: You cannot install APC and Zend Optimiser on the same server. You should choose one or the other.'''

Follow these steps to install APC.

===Download the correct version===
Download the windows binary for the PHP version you have installed from http://pecl4win.php.net/ext.php/php_apc.dll. Save into the PHP extensions folder, which is c:\php\ext by default.

Note: Make sure you choose the right extension for your version (branch) of PHP.

===Enable the APC extension in your PHP.INI file===
Edit the php.ini file and add the following line in the extensions section:

extension = php_apc.dll

Check that this has worked by restarting your web server and looking at the output of phpinfo from the Moodle administration screens or from a text file containing this line:

<?php phpinfo(); ?>

===Check the memory available===
To check the amount of memory that is available for APC to use:

* Run WordPad and create a text file called apcmeminfo.php.
* Copy and paste this line into the file

<?php print_r(apc_sma_info()); ?>

* Save the file into moodle/admin/apcmeminfo.php
* Browse to http://mymoodle.com/moodle/admin/apcmeminfo.php.
* Note the avail_mem value (in bytes)

... [avail_mem] => 31447368 ...

The total amount of memory used by the cache is given by this formula:

total_memory = apc.shm_segments * apc.shm_size

In this example, the available memory is approx 32Mb. Usually if we need more than 32Mb in our cache, we should increase the number of segments that APC uses. However, this is can cause web server faults, so it is best to increase the segment size instead.

When setting the total memory available for the cache, start with the lowest that a single Moodle install can work with (64Mb). This amount may not be enough if you have extra modules and blocks installed, so check by monitoring the cache regularly in the first two weeks that your server is running. Look at the monitoring section below and gradually increase your total cache memory until there is no more cache churn.

===Customizing APC settings for Moodle===
The default APC settings are as follows:

apc.cache_by_default = On
apc.enable_cli = Off
apc.enabled = On
apc.file_update_protection = 2
apc.filters = ''
apc.gc_ttl = 3600
apc.include_once_override = Off
apc.max_file_size = 1M
apc.num_files_hint = 1000
apc.optimization = Off
apc.report_autofilter = Off
apc.shm_segments = 1
apc.shm_size = 30
apc.slam_defense = 0
apc.stat = On
apc.ttl = 0
apc.user_entries_hint = 100
apc.user_ttl = 0
apc.write_lock = On

For a full explanation of these settings, see http://www.php.net/apc.

For a general Moodle installation several changes are needed. These are:
* The apc.shm_size (the size of the cache) which should be set initially to 64Mb.
* The apc.shm_segments which should be set to 1. This gives a total initial cache size of 64Mb.
* The apc.stat (file stating) which should be set to 1 otherwise you may get blank pages.
* The apc.max_file_size setting which should be increased to 10Mb.

Note that to disable APC temporarily set apc.enabled = 0 in PHP.INI and restart your webserver.

A working APC section of of PHP.INI is shown below, so copy and paste the following at the end of your PHP.INI file:

[APC]
apc.enabled = 1
apc.shm_segments = 1
apc.shm_size = 64
apc.max_file_size = 10M
apc.stat=1

The remainder of the settings can be left as their default.

===Set the temp directory===
APC needs a temporary directory to save its files. It will attempt to save the files in the windows temp directory, so set the C:\WINDOWS\TEMP directory to be writable by the web server user (for IIS this is IUSR_machine-name, for Apache no change to permissions are necessary), e.g. at least Read & Execute permissions.

==Monitoring and tuning the cache==
The APC source contains a php script that is useful for monitoring and tuning the performance of your cache.

* Download the APC monitoring file from http://pecl.php.net/package/apc and extract the contents.
* Look for the file apc.php as this is the file that displays APC monitoring information.
* Save the file apc.php into the /moodle/admin folder on your server.

Note: Once you have successfully installed APC, move this file to a password protected area for security.

* Verify that the script is working by browsing to http://mymoodle.com/moodle/admin/apc.php (or whatever the location of the apc.php file is on your server). You should see a graphical display of your cache with some statistical data on the left side.

To tune the cache, look at the ''General Cache Information'' and ''Detailed Memory Usage and Fragmentation'' sections. Watch the '''Cache Full Count''' and '''Fragmentation %''' indicators.
* If Cache Full Count > 0, this indicates that the cache is filling-up and churning as there is not enough memory allocated. To solve this problem increase the memory allocation (apc.shm_size).
* The Fragmentation % indicator should be 0% but may increase from time-to-time especially if the cache is churning.

==Checking performance==
To confirm that there has been an improvement in performance, try the following:

* Disable the cache in PHP.INI and restart the web server.
* Run ab.exe (included in the apache bin folder) at the command prompt as follows:

c:\apache2\bin>ab.exe -n 50 -c 1 -d http://mymoodle.com/moodle/index.php

* Note the transfer rate and the time per request values.
* Enable the cache in PHP.INI and restart the web server.
* Load http://mymoodle.com/moodle/index.php in your browser so that it is stored in the cache.
* Run ab.exe again and compare the transfer rate and time per request values. You should see an increase in both of these values by approximately 50%.

==Uninstalling APC==
To uninstall APC, add a semicolon to the extension line in your PHP.INI as follows:

;extension = php_apc.dll

Remember to restart your web server.

==See also==
* [http://moodle.org/mod/forum/discuss.php?d=56900 A discussion of an alternative to APC - Xcache]
* [http://cvs.php.net/viewvc.cgi/pecl/apc/TECHNOTES.txt?view=co APC technical notes]

[[Category:Administrator]]
[[Category:Installation]]
[[Category:Performance]]

[[pl:Instalacja APC w Windows]]

Arguments in favour of PostgreSQL

2008-01-19T20:40:38Z

Szymonk: added inter-language link to pl wiki

Martin Langhoff argues '''in favour of PostgreSQL''' (source: [http://moodle.org/mod/forum/discuss.php?d=24831#121862 Moodle over webct and LNLS at Athabasca University?] forum posting)

There are several reasons to go with Postgres, I'll try to make a brief outline. We run a variety of RDBMSs at Catalyst, and have a lot of in-house experience with them: Oracle, Postgres, MySQL and Progress, plus a few others. We also have experience with replicated databases, clustering and other tricks -- which we use for the backend of the .nz root domain servers as well as a few other mission-critical systems.

On the performance side, Postgres requires a bit more up-front configuration than MySQL. A well tuned Postgres is pretty close on SELECT performance to MySQL with small databases. With large tables MySQL has some bad performance problems, and Postgres performs much better.

Write performance is also an issue with MySQL -- with a lot of traffic, it has serious problems with concurrent writes. Under heavy load, Postgres performs much better.

But to tell you the truth, the real reason for choosing Postgres is reliability. We maintain a lot of databases, and Postgres is rock-solid reliable and has a focus on ACID-correctness: when it returns from a commit, the data is safely on disk and won't be lost -- barring actual disk problems, which we offset using RAID-1.

No matter how hard we try, MySQL databases with a lot of usage have recurring index corruption issues. If you look at the startup scripts for MySQL on most Linux distributions, they check for data corruption on every startup -- this is to mask the fact that it is a frequent occurrence.

And while this is passable with small installations where the data isn't mission critical, you have to consider how much you can trust such approch. And with large datasets, runing isamchk/myisamchk can take hours -- we cannot afford that.

The clustering solution for MySQL is being touted a lot, and I think it is a red herring. My main concern about is that it writes "asynchronously" -- that is, there is no guarantee that your data is on-disk safely. It'll get to the disk sometime. It'll get to the slaves... sometime. Hmmm.

Given that the MySQL cluster uses async writes, splitting read/writes between the master and the slaves breaks down in cases where we write some data, and read it back in immediately (or soon after). And this does happen in quite a few places.

And you also have to consider the performance boost of using async writes: if you tell a standalone Postgres or MySQL to use async writes, it'll run scale much better (should be able to handle up to 3-4 times more simultaneous writes). Once you do that, the performance advantage of the MySQL cluster mostly vanishes. It still has semi-hot takeover in case the master goes down, but Postgres can do that using Slony, and with better guarantess of consistency of the data in the slave.

In a nutshell, MySQL isn't normally very solid when it comes to ensure my data is safely stored on-the-disk, even if it theoretically guarantees that it's been saved. And MySQL Cluster says up-front that there isn't a guarantee any more. Riiiiiight wink

Michael is talking about having UPSs. We have a car-sized UPS and a container-sized on-site generator that auto-starts. And yet, I wouldn't depend on that for my DB consistency on a large Installation. So many things other than power can (and do) go amiss. If a process has a problem storing the data, the right thing is to tell that back to the user. With async writes, you end up with a queue of data that hasn't been stored yet, but you already told the user it was.

That's not what a database is supposed to do.

I am currently exploring some techniques similar to those being used in livejournal and slashdot. We should be able to increase Moodle scalability by cutting down on DB load by about 50%. This is happening slowly in the gaps between more urgent projects. Feel free to ping Richard or me if you're interested in that track.

===See Also===
* [https://docs.moodle.org/en/Step-by-step_Install_Guide_for_Ubuntu#Install_Postgresql_.28skip_MySQL.29 Installing Postgres on Ubuntu(Debian)]
[[Category:Administrator]]
[[Category:Performance]]

[[pl:Argumenty za PostgreSQL]]

Performance recommendations

2008-01-19T19:31:07Z

Szymonk: added inter-language link to pl wiki

Location: ''Administration > Server > 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 as has 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).

==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 area, 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.

'''See also''':
*[http://moodle.org/mod/forum/discuss.php?d=4801 Scalability] forum discussion.
*[http://moodle.org/mod/forum/discuss.php?d=57202 Moodle clustering] forum discussion.
*[http://moodle.org/mod/forum/discuss.php?d=44470 Software load balancing] forum discussion.
*[http://moodle.org/mod/forum/discuss.php?d=49986 TCP load balancing] forum dicsussion.

==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 (eg 4GB). 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.
* 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 Case Study on a server stress test with 300 users.[http://moodle.org/mod/forum/discuss.php?d=68579]
* See this accompanying report on network traffic and server loads. [http://elearning.sgu.ac.jp/doc/PT/]

==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 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] ([http://video.yahoo.com/video/play?vid=1040890 video]) 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] (recommended), [http://www.php-accelerator.co.uk/ PHPA], [http://trac.lighttpd.net/xcache/ Xcache] 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). Put the cached PHP pages on a [[TMPFS]] filesystem.
* Performance of PHP is better when installed as an '''Apache/IIS ISAPI module''' (rather than a CGI).
* 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.

===Apache performance===
* Set the '''MaxClients''' directive correctly. Use this formula to help (which uses 80% of available memory to leave room for spare):
MaxClients = Total available memory * 80% / Max memory usage of apache process
:Memory usage of apache process is usually 10MB, so a general rule of thumb is to divide your available memory in megabytes by 10 to get the value of MaxClients. To find the max memory usage of apache processes read the value from the shell command:
#ps -ylC httpd --sort:rss

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

:'''Warning''': Do not be tempted to set the value of MaxClients 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 '''MaxRequestsPerChild''' 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 '''HostnamesLookups 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
*'''Caching''' - Apache can be told to make pages load a lot faster by specifying that the browser should cache some various page elements such as images and reuse them from local memory rather than ask for them again every time a page is requested. How to do this varies slightly between OSes but there are two basic steps:

# Install and enable mod_expires - 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_expires.c>
ExpiresActive On
ExpiresDefault "access plus 1 seconds"
ExpiresByType text/html "access plus 1 seconds"
ExpiresByType image/gif "access plus 1 week"
ExpiresByType image/jpeg "access plus 1 week"
ExpiresByType image/png "access plus 1 week"
ExpiresByType text/css "access plus 1 week"
ExpiresByType text/javascript "access plus 1 week"
ExpiresByType application/x-javascript "access plus 1 week"
ExpiresByType text/xml "access plus 1 seconds"
</IfModule>

The effect is to make everything stay in the cache except HTML and XML, which change dynamically. It's possible to gain a several hundred percent decrease in load times this way. Adjust the cache times according to how often your images etc change.

More info: [http://www.metaskills.net/blog/heuristics/sysadmin/how-to-control-browser-caching-with-apache-2 www.metaskills.net]

* Alternatively, you can increase web server performance by using the '''light-weight webserver''' [http://www.lighttpd.net/ lighttpd] in combination with PHP in fastCGI-mode instead of Apache. Lighttpd has a lower memory consumption than Apache. One single apache process requires more RAM than the whole lighttpd with all of its fastCGI-processes together. Note that Lighttpd is relatively difficult to configure and administration takes a more time.

===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).

==Database performance==

Moodle contains a script which will display some key database performance statistics from the [http://phplens.com/lens/adodb/docs-perf.htm ADOdb performance monitor]. Run the script in your browser as in the following example:

http://www.mymoodle.com/admin/dbperformance.php

Use the data displayed as a guide to tune and improve the performance of your database server.

===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.
* 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
(min), and for Moodle 1.7 set
table_cache = 512
(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 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.
* Moodle's tables are in the MyISAM format, so '''turn InnoDB off''' as there is no performance gain. Add <code>skip-innodb</code> to your <code>my.cnf</code> file. If you must use InnoDB, you'll have to convert all of Moodle's tables. To do this run the innodb script:

http://www.mymoodle.com/admin/innodb.php

===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).
* [[Increasing the database connection lifetime | Try increasing the database connection lifetime]]
* [http://dev.mysql.com/doc/refman/5.0/en/server-parameters.html General advice on tuning MySQL parameters] (advice from the MySQL manual)

==Moodle Admin settings==
* In Moodle 1.7 or later, set the '''Cache type''' for your server: Site Admin -> Server -> Performance -> Cache type. There are several options available.
:*If you do not have eaccelerator or mmemcached installed, choose "internal" (which makes use of the record/internal cache - see the next bullet point).
:* If you have a single server and have compiled '''eaccelerator with shared memory support''', set the cache type to the eaccelerator option.
:* If you have a '''separate memcached server''', set the cache type to memcached and enter a csv list of server IP addresses.
* Enable the '''record/internal cache''': Site Admin -> Server -> Performance -> Record cache = True. Set the maximum amount of memory allocated to the cache in the Int Cache Max box. This will enable a primary cache for database records, without using any database engine cache, e.g. MySQL/PostgreSQL cache. See [http://tracker.moodle.org/browse/MDL-7196 this Tracker entry] for a full discussion.
* Enable the '''language cache'''.
* Large log files can cause overall performance to degrade over time. If you observe that the site has gradually got slower loading pages in the browser, '''reduce your Log life time''' setting (Admin/Server/Cleanup).
* Performance can be greatly improved by allowing Moodle to use the system '''zip/unzip''' commands (rather than PHP-based zip libraries) - visit Admin/Server/System Paths and enter the path to the relevant executables. (Similarly, filling in the path to '''du''' will improve Moodle's speed at listing directory contents.)
* Note that using '''secure web connections''' ('''https''' rather than '''http''') carries a higher processing burden, both for the webserver and the client - particularly because cacheing cannot be used as effectively, so the number of file requests is likely to increase dramatically. For this reason using https for all Moodle pages is not recommended. You can enable https just for the login screen, simply from Moodle's config page.
* Check your '''filters'''. Having too many filters active can have serious effects on server load, especially on lower-end systems. The number of active filters has a direct effect on the perceived latency of your site; that is the time taken for each page impression.
* Enable the '''text cache''' but do not "Filter all strings" unless you have a specific need. If in doubt profile the performance, and see how your changes affect the processing time.
* Check your '''anti-virus''' measures on the server. Although they are useful for preventing security holes being exploited, some "On-Demand" scanners can affect performance by scanning page content (word, ppt files etc).
* If there are performance problems loading course pages, check the '''Resource module settings'''. The setting resource_filterexternalpages is known to slow-down course pages and should be set to 'No' for better performance.
* Check your '''forum settings'''. To improve performance set forum_trackreadposts = No and forum_usermarksread = Yes (this will impact on the convenience of your users' forum experience). Also consider setting the time of the day when old posts are cleared from the read table (forum_cleanreadtime) to when your site is less busy.

==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 '''Quiz''' module is known to stretch database performance. Try to optimise your database server by tuning. See [http://moodle.org/mod/forum/discuss.php?d=25616&parent=120770 for a brief report on performance for 55 students simultaneously using quizzes]
** See this Case Study for an extensive server stress test with 300 quiz users.[http://moodle.org/mod/forum/discuss.php?d=68579] And this accompanying report on network traffic and server loads. [http://elearning.sgu.ac.jp/doc/PT/]
* 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/cron.php'') efficiency can be much improved.

==See also==

*Using Moodle [http://moodle.org/mod/forum/view.php?f=94 Servers and Performance] forum
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=57028 Performance perspectives - a little script] forum discussion

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

* [http://moodle.org/mod/forum/discuss.php?d=83057 Performance woes!]

[[Category:Performance]]

[[fr:Performance]]
[[ja:パフォーマンス]]
[[pl:Wydajność]]

PHP

2008-01-18T19:34:34Z

Szymonk: added inter-language link to pl wiki

PHP is the scripting language in which Moodle is developed. PHP does not stand alone, it is tightly integrated with a suitable HTTP Server. Most people use the [[Apache]] HTTP Server for this purpose although a number of others are supported.

PHP describes itself as "a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into [[HTML]]."

== Installation ==

Usually PHP is installed alongside [[Apache]] and [[MySQL]] in a combination known as AMP, see [[Installing AMP]] for details.

== Minimum version requirements ==

The minimum version of PHP required for Moodle is listed in the [[Installing_Moodle#Requirements|requirements section of the installation instructions]]

== See also ==

* [http://www.php.net/ The PHP home page]
* [http://en.wikipedia.org/wiki/PHP Wikipedia article on PHP]

[[Category:Administrator]]
[[Category:Developer]]

[[ja:PHP]]
[[pl:PHP]]

Installing Moodle

2008-01-07T19:58:25Z

Szymonk: added inter-language link to pl wiki

'''Firstly don't panic! :-)'''

This guide explains how to install Moodle for the first time. For some of these steps it goes into a lot of detail to try and cover the majority of possible web server setups, so this page may look long and complicated. Don't panic, once you know how to do it you can install Moodle in minutes!

If you have problems please read this page carefully - most common issues are answered in here. If you still have trouble, you can seek help from the Moodle community via [http://moodle.org/course/view.php?id=5 moodle.org Using Moodle].

Another option is to contact a [http://moodle.com/hosting/ Moodle Partner providing Moodle hosting] who can completely maintain Moodle for you, so that you can ignore all this and get straight into educating! A Moodle partner is the preferred option but if you decide to choose a hosting company that has cpanel then [http://otaru-jc.ac.jp/hagley/settingupmoodleonhostingwithcpanel.swf this tutorial will guide you] through the process of choosing a host and setting up moodle via cpanel.

If you want to run Moodle on your own computer and this page looks a bit daunting, then please see our guides: [[Installing AMP |Installing Apache, MySQL and PHP(AMP)]] or [[Complete install packages| how to install one of Moodle's complete packages]]. They provide alternative instructions to install all this on most popular platforms.
==Table of Contents==
__TOC__

==Requirements==

Moodle is primarily developed in Linux using [[Apache]], [[MySQL]] and [[PHP]] (also sometimes known as the LAMP platform), but is also regularly tested with Windows XP/2000/2003 (WAMP), Solaris 10 (Sparc and x64), Mac OS X and Netware 6 operating systems. Support for PostgreSQL, Oracle and Microsoft SQL Server is also available.

'''Note if you are using a hosted account''': Most web hosts support all of these requirements by default. You should contact your web host's support desk to check that this is the case '''before''' signing-up with them. It is especially important to ask about any PHP memory limits or MySQL question limits. If your prospective host does not provide a service which meets these requirements, or you are already signed up with them, ask them why and consider taking your business elsewhere if they do not change.

The requirements for Moodle are as follows:

'''Hardware''' (unless you are using a hosted server).
* Disk space: 160MB free (min). You will require more free space to store your teaching materials.
* Memory: 256MB (min), 1GB (recommended). The general rule of thumb is that Moodle can support 50 ''concurrent'' users for every 1GB of RAM, but this will vary depending on your specific hardware and software combination.
'''Software'''
* Web server software. Most people use [[Apache]], but Moodle should work fine under any web server that supports [[PHP]], such as [[IIS]] on Windows platforms. PHP does impose requirements on versions of web servers, however these are complex and the general advice is to use the newest version possible of your chosen web server.
* PHP scripting language. (Please note that there have been issues installing Moodle with [http://www.php-accelerator.co.uk PHP-Accelerator]). There are currently two versions (or branches) of PHP available: PHP4 and PHP5 and the version requirements are listed below.
** For Moodle version 1.4 or later: PHP4 (version 4.1.0 or later) or PHP5 (version 5.1.0 or later) are supported.
** For Moodle version 1.6 or later: the PHP4 (version 4.3.0 or later) or PHP5 (version 5.1.0 or later) are supported.
** Future Moodle versions 2.0 or later will not support PHP4 and will require PHP5 (version 5.2.0 or later).
** PHP Settings
*** ''safe_mode'' needs to be OFF (check in your php.ini or Apache configuration file).
*** ''memory_limit'' should be at least 16M (32M is recommended for Moodle 1.7 and 40M for Moodle 1.8 or later). Large sites may need more than 128M. PHP 5.2.x requires higher memory_limit values than previous versions of PHP. 64bit operating systems require even more memory.
*** ''session.save_handler'' needs to be set to files.
** PHP Extensions and libraries
*** The mbstring extension is recommended for Moodle 1.6 or later.
*** The iconv extension is recommended for Moodle 1.6 or later.
*** [http://www.libgd.org/ GD library] and the [http://www.freetype.org/ FreeType 2] library and extensions are needed to be able to look at the dynamic graphs that the logs pages make.
*** The mysql extension is required if you are using the MySQL database. Note that in some Linux distributions (notably Red Hat) this is an optional installation.
*** The pgsql extension is required if you are using the PostgreSQL database.
*** The zlib extension is required for zip/unzip functionality.
*** The curl extension is recommended for Moodle 1.8 or later.
*** The tokenizer extension is recommended for Moodle 1.8 or later.
*** The curl and openssl extensions are required for the Moodle network functionality (Moodle 1.8 or later).
*** 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).
* A working database server: [[MySQL]] or [[PostgreSQL]] are completely supported and recommended for use with any version of Moodle. Support for Microsoft SQL Server and Oracle has been added in Moodle 1.7. MySQL is ''the'' choice for many people because it is very popular, but there are some [[Arguments in favour of PostgreSQL|arguments in favour of PostgreSQL]], especially if you are planning a large deployment.
** For Moodle 1.5 or later, MySQL (version 3.23 or later) or PostgreSQL (7.4 or later).
** For Moodle 1.6 or later, MySQL (version 4.1.12 or later) or PostgreSQL (7.4 or later).
** For Moodle 1.7 or later, MySQL (version 4.1.12 or later), PostgreSQL (7.4 or later) or Microsoft SQL Server 2005 (version 9 or [http://moodle.org/mod/forum/discuss.php?d=59284 SQL Server Express 2005])
: MySQL Notes: For Moodle 1.6 or later, If you use latin languages only you can use MySQL 4.1.12. If you are using non-latin languages you require MySQL 4.1.16 or later. Currently the MySQL setting "strict mode" must be OFF (set to "" or "MYSQL40") in the MySQL configuration file.
: PostgreSQL Notes: The minimum version of PostgreSQL is 7.4 and Moodle is widely used with 8.0 and 8.1.

[[Installing_Moodle#Table_of_Contents|Table of Contents]]

== How many users? ==

In addition to the hardware and software requirements, you will also need to think about the capacity of your Moodle installation in terms of the number of users it can handle. There are two numbers to plan for:

* '''Browsing users''': the maximum number of users able to browse your Moodle site. This is the number of computers in your organization or on your course (whichever is greater).
* '''Concurrent database users''': the maximum number of concurrent database users (needed for Moodle activities such as quizzes). This is the number of users who will be using Moodle at the same time. In an educational institution, use your timetable/roster to obtain this figure.

Once you know these figures for your users, you can start work out if your Moodle installation can support this capacity. The exact number of users depends on your hardware/software/network combination. Usually the amount of memory installed (RAM) is the deciding factor but a faster overall processor speed will also help in reducing waiting times for pages to load.

The general rule of thumb for a single server is that the approx max concurrent users = RAM (GB) * 50 and the approx max browsing users = Approx max concurrent users * 5. As an example, a university with 500 total computers on campus and 100 concurrent users at any time will need approx 2GB of RAM on the one server to support the number of concurrent users.

'''Note if you are using a hosted account''': Ask your provider what limits are placed on the number of concurrent database connections and the processor load. This will give a good estimate of the number of users your Moodle install can manage.

'''Note:''' As of August 31, 2007, the moodle 1.8.2+ codes are still not suitable for large installation, especially if you have large number (e.g. 20,000+) of courses. The main reason is the codes related to ROLES are still not fully optimized with database queries and still need some work. If you are planning to use 1.8.x codes for a larger institution, please make sure that you have sufficient time to do your own testing and performance profiling.

[Update] This performance issue has been improved quite a bit in the most recent 1.8.3+ version (see this thread discussion: http://moodle.org/mod/forum/discuss.php?d=83281). However, you should still plan with caution if you are planning to use Moodle 1.8.x code base for larger installation.

[[Installing_Moodle#Table_of_Contents|Table of Contents]]

== Download and copy files into place ==

There are two ways to get Moodle, either as a compressed package or via CVS.
* There are two types of compressed packages on the [http://download.moodle.org/ download page: http://download.moodle.org/], the standard distribution with Moodle only files and the [[Complete install packages|complete install]], which contains programs to operate Moodle in a web environment.
* To use CVS, helpful instructions are available at the [[CVS_for_Administrators | CVS for Administrators]] page. The full [http://cvs.moodle.org/moodle/ Moodle CVS repository] is also available for browsing.

After downloading, unpack the archive using either
tar -zxvf [filename]
or
unzip [filename]
as appropriate.

If using CVS, run the CVS Checkout command.

You will now be left with 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>'''.

If you are downloading Moodle to your local computer and then uploading it to your web site, it is usually better to upload the whole archive as one file, and then do the unpacking on the server. Even web hosting interfaces like cPanel allow you to uncompress archives in the "File Manager".

=== Structure of moodle directory ===

You can safely skip this section, but here is a quick summary of the contents of the Moodle folder, to help get you oriented:

:''config.php'' - contains basic settings. This file does not come with Moodle - you will create it.
:''install.php'' - the script you will run to create config.php
:''version.php'' - defines the current version of Moodle code
:''index.php'' - the front page of the site
:''admin/'' - code to administrate the whole server
:''auth/'' - plugin modules to authenticate users
:''blocks/'' - plugin modules for the little side blocks on many pages
:''calendar/'' - all the code for managing and displaying calendars
:''course/'' - code to display and manage courses
:''doc/'' - help documentation for Moodle (eg this page)
:''files/'' - code to display and manage uploaded files
:''lang/'' - texts in different languages, one directory per language
:''lib/'' - libraries of core Moodle code
:''login/'' - code to handle login and account creation
:''mod/'' - all the main Moodle course modules are in here
:''pix/'' - generic site graphics
:''theme/'' - theme packs/skins to change the look of the site.
:''user/'' - code to display and manage users

[[Installing_Moodle#Table_of_Contents|Table of Contents]]

== Setting-up your system==
To ensure that Moodle will install successfully, you need to check that the web server settings are correct, then create a blank database for Moodle to use and finally create a directory on your hard disk for Moodle to save your materials and other files you upload into your courses.

=== Check web server settings ===

*Firstly, make sure that your web server is set up to use index.php as a default page (perhaps in addition to index.html, default.htm and so on). In Apache, this is done using a DirectoryIndex parameter in your httpd.conf file. Mine usually looks like this:

'''DirectoryIndex''' index.php index.html index.htm

:Just make sure index.php is in the list (and preferably towards the start of the list, for efficiency).

*Secondly, '''if you are using Apache 2''', then you should turn on the ''AcceptPathInfo'' variable, which allows scripts to be passed arguments like <nowiki>http://server/file.php/arg1/arg2</nowiki>. This is essential to allow relative links between your resources, and also provides a performance boost for people using your Moodle web site. You can turn this on by adding these lines to your httpd.conf file.

'''AcceptPathInfo''' on

=== Check PHP settings ===
Moodle requires a number of PHP settings to be active for it to work. '''On most servers these will already be the default settings'''. However, some PHP servers (and some of the more recent PHP versions) may have things set differently. These are defined in PHP's configuration file (usually called '''php.ini'''):

magic_quotes_gpc = 1 (preferred but not necessary)
magic_quotes_runtime = 0 (necessary)
file_uploads = 1
session.auto_start = 0
session.bug_compat_warn = 0

:You may also want to set other, optional php.ini file settings while you are already editing it. For instance, you may want to reset the maximum upload size of file attachments, which usually defaults to 2M(egabytes). For instance, to set these to 16 Megabytes:

post_max_size = 16M
upload_max_filesize = 16M

[[Installing_Moodle#Table_of_Contents|Table of Contents]]

=== Using a .htaccess file for webserver and PHP settings ===

Use the above if you can directly edit your server's files, but if you are setting-up Moodle on a webhost, or don't have access to '''httpd.conf''' or '''php.ini''' on your server, or you have Moodle on a server with other applications that require different settings, then don't worry, you can often still override the default settings. This only works on Apache servers and only when Overrides have been allowed in the main Apache configuration.

* Create a file called '''.htaccess''' in Moodle's main directory that contains lines like the following.

DirectoryIndex index.php index.html index.htm
php_flag magic_quotes_gpc 1
php_flag magic_quotes_runtime 0
php_flag file_uploads 1
php_flag session.auto_start 0
php_flag session.bug_compat_warn 0

:If you have Apache version 2 installed, add these lines:

<IfDefine APACHE2>
AcceptPathInfo on
</IfDefine>

:Otherwise add this single line:

AcceptPathInfo on

* Optionally, you can also do things like define the maximum size for uploaded files, etc by adding these lines:

LimitRequestBody 0
php_value upload_max_filesize 2M
php_value post_max_size 2M

* The easiest thing to do is just copy the sample file from lib/htaccess and edit it to suit your needs. It contains further instructions. For example, in a Unix shell:

cp lib/htaccess .htaccess

'''Note''': Use a .htaccess file only [http://httpd.apache.org/docs/1.3/howto/htaccess.html#when as a last resort] as it can have an impact on the performance of your Moodle site and cause pages to load slowly on your browser.

[[Installing_Moodle#Table_of_Contents|Table of Contents]]

=== Creating an empty database ===

You need to create an empty database (eg "''moodle''") in your database system along with a special user (eg "moodleuser") that has access to that database (and that database only). You could use the "root" user if you wanted to for a test server, but this is not recommended for a production system: if hackers manage to discover the password then your whole database system would be at risk, rather than just one database.

::'''Warning''': Bear in mind that, as of Moodle version 1.5.x, Moodle doesn't work with MySQL 5.x's strict mode setting (STRICT_TRANS_TABLES and/or STRICT_ALL_TABLES) -- see [http://moodle.org/mod/forum/discuss.php?d=58552 forum discussion]. So if you are using MySQL 5.x, edit MySQL's configuration file (called "my.ini" in Windows and "my.cnf" on Unix/Linux) and comment out that option or set it to <code>sql-mode=<nowiki>''</nowiki></code>. You have to restart MySQL after changing this setting. <br><br> If you do not have access to your server, use PHPMyAdmin (or another MySQL client) and enter the command <code>SET @@global.sql_mode=<nowiki>''</nowiki>;</code> (be sure to use single quotes, and don't forget the semicolon).

====Using a hosted server====
If you are using a webhost, they will probably have a control panel web interface for you to create your database.

The '''[http://www.cpanel.com/ cPanel]''' system is one of the most popular of these. To create a database in cPanel,

# Click on the "'''MySQL Databases'''" icon.
# Type "moodle" in the database field and click "'''Add Database'''".
# Type a username and password (not one you use elsewhere) in the respective fields and click "'''Add User'''".
# Now use the "'''Add User to Database'''" button to give this new user account "'''ALL'''" rights to the new database.
# Note that the username and database names may be prefixed by your cPanel account name. When entering this information into the Moodle installer - use the full names.

====Using the command line====

If you have access to Unix or Windows command lines then you can do the same sort of thing by typing commands. You should do this using the MySQL Client program as follows (commands which you type-in are shown in bold):

- Start the MySQL Client program:
#'''mysql -u root -p'''
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 2 to server version: 5.0.22-log

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql>

- The prompt changes to "mysql>" to indicate that you are now working in the MySQL Client program. When working in MySQL, all commands which you type-in must end in a semi-colon. (If you hit the Enter key without the final semi-colon, you'll get the line continuation symbol '->'; this is your second chance to type the semi-colon and hit Enter.)

- Begin by checking for any existing databases called "moodle" - if there are any you should change the name in all the commands which follow:
mysql> '''SHOW DATABASES;'''
+-------------------------+
| Database |
+-------------------------+
| information_schema |
| mysql |
| test |
+-------------------------+
3 rows in set (0.03 sec)

- Create a database to store the Moodle tables. We'll call this "moodle", as there are none with that name already in the above list, but change it if you need to.
mysql> '''CREATE DATABASE moodle;'''
Query OK, 1 row affected (0.00 sec)

- Change the default character set and collation of the "moodle" database to UTF8. Leave this out if you are installing Moodle 1.5 or earlier):
mysql> '''ALTER DATABASE moodle DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci;'''
Query OK, 1 row affected (0.00 sec)

- Create a username and password to access the database "moodle" and grant database access permissions. We'll call the user "moodleuser" and set the password as "yourpassword". It's a good idea to change these for your installation however most people keep the username as "moodleuser". Remember the username and password you have set, as you'll need it in the configuration screens later. This is a long command so has been split over several lines by pressing the Return key.
mysql> '''GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,CREATE TEMPORARY TABLES,'''
-> '''DROP,INDEX,ALTER ON moodle.*'''
-> '''TO moodleuser@localhost IDENTIFIED BY 'yourpassword';'''
Query OK, 0 rows affected (0.01 sec)

:'''Security Warnings''': Never leave the password as the one shown here. Make sure you have a strong password (a mixture of letters and numbers, upper and lower case). Avoid granting "ALL" permissions on the database.
: '''Note''': For MySQL 4.0.1 or earlier, you don't need the CREATE TEMPORARY TABLES permission.

- Exit the MySQL Client program:
mysql> '''QUIT'''
Bye
#

- Reload the grant tables using the mysqladmin program:
#'''mysqladmin -u root -p reload'''
Enter password:
#

And some example command lines for PostgreSQL:

# su - postgres
> psql -c "create user moodleuser createdb;" template1
> psql -c "create database moodle <font color="red">with encoding 'unicode'</font>;" -U moodleuser template1
> psql -c "alter user moodleuser nocreatedb;" template1
> psql -c "alter user moodleuser with encrypted password 'yourpassword';" template1
> su - root
# /etc/init.d/postgresql reload

If the Postgres create database command above (>psql -c "create database moodle...") gives an error message you may want to try:
psql -c "create database moodle with template=template1 encoding = 'unicode' owner = moodleuser <br> location = '/var/mydata';"

If the create database command asks you for a password, run the line containing 'encrypted password' first before proceeding.

'''See also''':
* Step-by-step instructions on [https://docs.moodle.org/en/Step-by-step_Install_Guide_for_Ubuntu installation for Ubuntu(Debian)]

[[Installing_Moodle#Table_of_Contents|Table of Contents]]

=== Creating the data directory (moodledata) ===

Moodle will also need some space on your server's hard disk to store uploaded files, such as course documents and user pictures. The Moodle installer tries hard to create this directory for you but if it fails then you will have to create a directory for this purpose manually.

'''Security warning''': For security purposes, it's best that this directory is NOT accessible directly via the web. The easiest way to do this is to simply locate it OUTSIDE the web directory, but if you must have it in the web directory (and you are using Apache) then protect it by creating a file in the data directory called '''.htaccess''', containing these lines:

order deny,allow
deny from all

'''Ownership & Permissions''': To make sure that Moodle can save uploaded files in this directory, check that the web server software has permission to read, write and execute in this directory. On Unix machines, this means setting the owner of the directory to be something like "nobody" or "apache", and then giving that user read, write and execute permissions. As an example, to change the owner to "nobody" you could use:

chown -R nobody:apache moodledata

To change the permissions so that the owner has read,write and execute permissions, use something like this:

chmod -R 0770 moodledata

'''Note''': If you are receiving permission denied messages, try ''chmod -R 0770 moodledata'' and then adjust the settings so that they are more secure. A more secure setting is ''chmod -R 0750 moodledata''. According to the comments in config-dist.php, "On hosting systems you might need to make sure that your group has no permissions at all while others have full permissions." To do this you could use ''chmod -R 707 moodledata''. See also the [[Security | security page]].

Remember that by default moodle will issue a warning about moodle data directories created inside the web directory, but otherwise this directory can be located where you wish. You can later move or change the location of this directory, but if you do, be sure to edit the setting in the '''config.php''' file that sets this; e.g. if moodledata is under a directory called data, then it would look like this:

$CFG->dataroot = '/data/moodledata';

'''CPanel and webhosts''': On cPanel systems you can use the "File Manager" to find the folder, click on it, then choose "Change Permissions". On many shared hosting servers, you will probably need to restrict all file access to your "group" (to prevent other webhost customers from looking at or changing your files), but provide full read/write access to everyone else (which will allow the web server to access your files). Speak to your server administrator if you are having trouble setting this up securely. In particular it will not be possible to create a usable data directory on sites that use a PHP feature known as "'''Safe Mode'''".

[[Installing_Moodle#Table_of_Contents|Table of Contents]]

== Run the installer script to create config.php ==

To run the installer script (install.php), just try to access your Moodle main URL using a web browser, or access '''<nowiki>http://yourserver/install.php</nowiki>''' directly.

(The Installer will try to set a session cookie. If you get a popup warning in your browser make sure you accept that cookie!)

Moodle will detect that configuration is necessary and will lead you through some screens to help you create a new configuration file called '''config.php'''. At the end of the process Moodle will try and write the file into the right location, otherwise you can press a button to download it from the installer and then upload '''config.php''' into the main Moodle directory on the server.

Along the way the installer will test your server environment and give you suggestions about how to fix any problems. For most common issues these suggestions should be sufficient, but if you get stuck, check in the Installation Forum for more help.

[[Installing_Moodle#Table_of_Contents|Table of Contents]]

== Go to the admin page to continue configuration ==

Once the basic config.php has been correctly created in the previous step, trying to access the front page of your site will take you to the "admin" page for the rest of the configuration.

The first time you access this admin page, you will be presented with a GPL "shrink wrap" agreement with which you must agree before you can continue with the setup.

Now Moodle will start setting up your database and creating tables to store data. Firstly, the main database tables are created. You should see a number of SQL statements followed by status messages that look like this:

CREATE TABLE course (
id int(10) unsigned NOT NULL auto_increment,
category int(10) unsigned NOT NULL default '0',
password varchar(50) NOT NULL default <nowiki>''</nowiki>,
fullname varchar(254) NOT NULL default <nowiki>''</nowiki>,
shortname varchar(15) NOT NULL default <nowiki>''</nowiki>,
summary text NOT NULL,
format tinyint(4) NOT NULL default '1',
teacher varchar(100) NOT NULL default 'Teacher',
startdate int(10) unsigned NOT NULL default '0',
enddate int(10) unsigned NOT NULL default '0',
timemodified int(10) unsigned NOT NULL default '0',
PRIMARY KEY (id)
) TYPE=MyISAM;

<font color="green">SUCCESS</font>

...and so on, followed by: <font color="green">Main databases set up successfully.</font>

If you don't see these, then there must have been some problem with the database or the configuration settings you defined in config.php. Check that PHP isn't in a restricted "Safe Mode" (commercial web hosts sometimes have safe mode turned on). You can check PHP variables by creating a little file containing '''<?php phpinfo() ?>''' and looking at it through a browser. Check all these and try this page again.

Scroll down the very bottom of the page and press the "Continue" link.

You should now see a form where you can define more configuration variables for your installation, such as the default language, SMTP hosts and so on. Don't worry too much about getting everything right just now - you can always come back and edit these later on using the admin interface. The defaults are designed to be useful and secure for most sites. Scroll down to the bottom and click "Save changes".

If (and only if) you find yourself getting stuck on this page, unable to continue, then your server probably has what I call the "buggy referrer" problem. This is easy to fix: just turn off the "secureforms" setting, then try to continue again.

Next you will see more pages that print lots of status messages as they set up all the tables required by the various Moodle module. As before, they should all be <font color="green">green</font>.

Scroll down the very bottom of the page and press the "Continue" link.

The next page is a form where you can define parameters for your Moodle site and the front page, such as the name, format, description and so on. Fill this out (you can always come back and change these later) and then press "Save changes".

Finally, you will then be asked to create a top-level administration user for future access to the admin pages. Fill out the details with your own name, email etc and then click "Save changes". Not all the fields are required, but if you miss any important fields you'll be re-prompted for them.

'''Make sure you remember the username and password you chose for the administration user account, as they will be necessary to access the administration page in future.'''

(If for any reason your install is interrupted, or there is a system error of some kind that prevents you from logging in using the admin account, you can usually log in using the default username of "'''admin'''", with password "'''admin'''".)

Once successful, you will be returned to the home page of your new site! Note the administration links that appear down the left hand side of the page (these items also appear on a separate Admin page) - these items are only visible to you because you are logged in as the admin user. All your further administration of Moodle can now be done using this menu, such as:

* creating and deleting courses
* creating and editing user accounts
* administering teacher accounts
* changing site-wide settings like themes etc

But you are not done installing yet! There is one very important thing still to do (see the next section on cron).

[[Installing_Moodle#Table_of_Contents|Table of Contents]]

== Set up cron ==

Please refer to the [[Cron|Cron instructions]].

== Set up backups ==

Please refer to the [[Backup settings| backup instructions]].

[[Installing_Moodle#Table_of_Contents|Table of Contents]]

== Create a new course ==

Now that Moodle is running properly, you can try creating a new course to play with.

Select "Create a new course" from the Admin page (or the admin links on the home page).

Fill out the form, paying special attention to the course format. You don't have to worry about the details too much at this stage, as everything can be changed later by the teacher. Note that the yellow help icons are everywhere to provide contextual help on any aspect.

Press "Save changes", and you will be taken to a new form where you can assign teachers to the course. You can only add existing user accounts from this form - if you want to create a new teacher account then either ask the teacher to create one for themselves (see the login page), or create one for them using the "Add a new user" on the Admin page.

Once done, the course is ready to customize, and is accessible via the "Courses" link on the home page.

==See also==

* [[Installation FAQ]]
*[[Complete install packages]] might be an easier first time installs on some systems
* [[Installing Apache, MySQL and PHP]] - Open source programs that can run Moodle on the web or on a desktop
* [[Upgrading Moodle]]
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=42688 Selecting a web host for Moodle] forum discussion
* [[masquerading|Masquerading]] - Running Moodle behind a masquerading/NAT firewall

[[Category:Installation]]

[[cs:Instalace]]
[[de:Installieren von Moodle]]
[[es:Instalación de moodle]]
[[fr:Installation de Moodle]]
[[ja:Moodleのインストール]]
[[nl:Installatiegids]]
[[ru:Установка Moodle]]
[[sk:Inštalácia]]
[[zh:安装Moodlezh:]]
[[pl:Instalacja Moodle]]

Installing AMP

2008-01-06T12:58:44Z

Szymonk: added inter-language link to pl wiki

AMP or AMPPlite stands for '''A'''pache, '''M'''ySQL & '''P'''HP. Moodle is written in a scripting language called [[PHP]] and stores most of its data in a database. The recommended database is [[MySQL]]. Before installing Moodle you must have a working PHP installation and a working database to turn your computer into a functional web server platform. XAMP is a Windows and MAMP is a Mac OS version.
Moodle does have [[Complete install packages]] in the [http://download.moodle.org/ download section] as well as the Moodle only package.

The AMP individual applications can be tricky to set up for average computer users. This page has been written to try to make this process as simple as possible for different platforms.

== Hosting Service ==

Unfortunately hosting services vary quite a lot in the way they work. Some will even install Moodle for you.

Most will offer a web-based control panel to control your site, create databases and set up cron. Some may also offer terminal access via ssh, so that you can use the command shell to do things.

You should work your way through the [[Installing Moodle|Installation guide]] and take each step at a time. Ask your hosting provider if you get stuck.

== Mac OS X ==

The easiest way to do this is use the [[Apache]] server that Apple provides, and add PHP and MySQL using Marc Liyanage's packages. Both of the pages below come with good instructions that we won't duplicate here:

* '''PHP''': Download from here: http://www.entropy.ch/software/macosx/php/
* '''MySQL''': Download here: http://www.entropy.ch/software/macosx/mysql/

Once these are installed the standard [[Installing Moodle|Installation guide]] should be fairly straightforward.

Go here for a [[Step-by-step Guide for Installing Moodle on Mac OS X 10.4 Client]] (not server) Mac.

== Red Hat Linux ==

You should install all available RPM packages for Apache, PHP and MySQL. One package that people frequently forget is the php-mysql package which is necessary for PHP to talk to MySQL.

Once these are installed the standard [[Installing Moodle|Installation guide]] should be fairly straightforward.

A more detailed walkthrough is here: [[RedHat Linux installation]]

== Windows ==

Installing Moodle '''for the first time''' on a [[Localhost]] (a stand alone computer) is easy and can be a very useful tool even if a web based production Moodle Server is available for use. These instructions work on a Windows XP computer.
#On the [http://download.moodle.org/windows/ Windows packages] download page, choose the version you would like. Click on the download link in the rightmost column. This will download a large zip file.
#Unzip the downloaded file at c: and keep the path structure for all the files.
#Rename the just created c:\moodle to c:\xampplite (c:\xampplite will be our example) but you could rename it c:\moodle16 or c:\moodle17 or C:\testMoodle or whatever .
#Using Windows Explorer run the file c:\xampplite\setup_xampp.bat which will make sure all the configuration files use c:\xampplite as the home or root directory.
#The following steps assume that the web server will be able to use port 80 on your computer. See [[Windows_installation_using_XAMPP#Skype |troubleshooting if you are running Skype]] which also likes to use this port as a default.
#Be sure that you are administrator or at least that you have rights to install new services.
#There many ways to start the localhost webserver from this point for the Moodle install. Here are two ways.
##Slightly faster
###Using Windows Explorer run the file c:\xampplite\restart_xampp.bat and do not close the window that opens.
##Still fast
###In Windows Explorer click on c:\xampplite\apache_start to start the Apache web server. This opens a new window that you should leave open.
###In Windows Explorer click on c:\xampplite\mysql_start to start the MySQL database server. This opens yet another new window that you should leave open.
#In your favorite Web browser, go to the address bar and type "localhost" or "127.0.0.1" and press enter or click go.
#This will start the Moodle Install process, which the [[Installing Moodle]] [[Installing_Moodle#Go_to_the_admin_page_to_continue_configuration| MoodleDoc page section]] describes in a little bit more detail. This can take some time for a new user. '''Don't panic''', you can change things later and the install process will tell you what you absolutely have to fill in or correct.

===Easier Moodle restarts===
There are lots of ways to start a Moodle after an install. Most Moodlers will have one or more "localhost" links on their computer installed in "Favorites" or even as a browser's default opening screen. But first a web server has to be started. Here are two ways to start them.
====Automatic Windows services startup====
In order to make starting Moodle more convenient in the future you could install the web and database servers as Windows services that are started automatically. To do this go to Start -> Run... and type the command "c:/xampplite/service.exe -install" into Open box. Then click OK.

Start Moodle by typing localhost in the web browser and/or adding localhost as a favorite site.
====Single button service startups====
Sometimes there are more than one localhost installed on a computer. Create a shortcut on the start menu, favorites or desktop that points to each specific file like c:\xampplite\restart_xampp.bat . Label each shortcut to a localhost differently, for example C_MoodleXampp, or Moodle16 or Moodle17 or whatever.

Start Moodle by placing localhost in the web browser or adding it as a favorite site. Whichever localhost you restarted, that is the Moodle your web browser will find.

==Other install options==
Instead of using this package you can also install XAMPP and Moodle separately as explained on the page [[Windows_installation_using_XAMPP]].

As an alternative to the above package you could use a package like EasyPHP that bundles all the software you need into a single Windows application. Note that the EasyPHP 1.8 uses older versions of the software that are too old for Moodle 1.6. Also many menus for EasyPHP are still in French. EasyPHP may be a good option again once its version 2.0 is released.

Here you can find steps for an [[IIS]]: [[Windows installation]] for XAMPP or Windows 2003 .

==Testing PHP==
Once you have installed your web server and PHP you should be able to create a file (for example phpinfo.php in the document root) with the following in it:

<?php phpinfo()?>

You should be able to open this file in a web browser by going to to the URL '''localhost/phpinfo''' and see a web page that has PHP status information in it such as [[phpinfo|this]].

==See also==

*[[Installing Moodle]]
*[[Installation FAQ]]
*[[Upgrading Moodle]]
*[[Debian GNU/Linux installation]]
*[[Complete install packages]], also includes instructions for creating a stand alone (localhost) installation on a single computer.

[[Category:Installation]]

[[es:Instalación AMP]]
[[fr:Installation de AMP]]
[[ja:AMPのインストール]]
[[ru:Установка AMP]]
[[pl:Instalacja AMP]]

Category:Installation

2008-01-06T12:57:56Z

Szymonk: added inter-language link to pl wiki

Pages related to [[Installing Moodle|installing]] and [[Upgrading|upgrading]] Moodle.

[[Category:Administrator]]

[[fr:Catégorie:Installation]]
[[pl:Kategoria:Instalacja]]

Administrator documentation

2008-01-06T11:05:26Z

Szymonk:

The purpose of this page is to list useful links by general topics for administrators.

== Installation & Upgrading ==

*[[Installation Quickstart]] for an overview of the installation steps
*[[Installing Moodle]] for detailed installation instructions
*[[Installation FAQ]]
*[[Installing AMP|Installing Apache, MySQL and PHP]]
*[[Upgrading|Upgrading Moodle]]

== System-specific Instructions & Packages ==

* [[SUSE Linux Server 10|Automated Installation Guide for SUSE Linux Enterprise Server 10]] operating system
* [[RedHat Linux installation|Step by Step Installation Guide for RedHat]] operating system
* [[Debian GNU/Linux installation|Step by Step Installation Guide for Debian GNU/Linux]] operating system
* [[Step-by-step Install Guide for Ubuntu]]
* [[Windows installation|Complete Install Packages for Windows XP and instructions for Windows NT/2000/2003 servers]]
* [[Complete Install Packages for Mac OS X | Complete Install Packages for Mac OS X 10.3/10.4/10.5]]
* [[Step-by-step Guide for Installing Moodle on Mac OS X 10.4 Client | Step-by-Step Guide for Installing Moodle using the internal web server on Mac OS X 10.4 Client]]
* [[1and1_MySQL_installation | Installation on 1and1 web hosting]]
* [[OLPC XS installation|Step by Step Installation Guide for the One Laptop per Child XS Server (Beta)]]

==Security, Performance and Roles==

*[[Security]] contains important security procedures for a production site
*[[Performance | Performance and optimization]] for ideas on improving the speed of your installation
*[[Manage roles | Managing roles]] For Moodle 1.7 and later

== FAQs ==

*[[Installation FAQ]]
*[[Administration FAQ]]
*[[Backup FAQ]]

== Configuration Settings ==
*[[Site administration block]] contains configuration setting links
*[[Notification page]] used to update versions
*[[Variables]]
*[[Site settings]]
*[[Themes]]
*[[Language]]
*[[Activity modules administration]]
*[[Blocks administration]]
*[[Filters]]
*[[Backup settings]]
*[[Editor settings]]
*[[Calendar settings]]
*[[Maintenance mode]]

* See also: [[Location of admin settings in 1.7|Comparison between configuration settings in Moodle 1.6 & 1.7]]

==User Management==

*[[Authentication]]
*[[Edit user accounts]]
*[[Add new user|Add a new user]] - on a site
*[[Flat file|Upload users]] - from a file to a site
*[[Enrolment plugins]]
*[[Roles and capabilities|Assigning user a role]] - typical assignments include:
**[[Students|Enrol students in a course]]
**[[Courses (administrator)|Assign teachers]] - to a course
**[[Assign creators|Assign course creators]] - in a site
**[[Assign administrators]] - in a site

==Other==

*[[Courses (administrator)|Courses]] and [[Course formats|course formats]]
*[[Reports (administrator)]] and [[Logs]]
*[[Site files]]
*[[Moodle database|Database]]
*[[Environment]]
*[[Moodle Network]] and Moodle Community Hub
*[[Streaming Media]]
*[[Case studies (administrator)]]
*[[Anti-virus]]

==See also==

*[[:Category:Administrator | Index of all Administrator-related pages]]
*[[Integrations]]
*[[CVS for Administrators]]
*[[Email processing]]
*[[Search engine optimization]]
*[[Messaging]]
*[[Migration]]
*[[Metacourses]]
*[[Block layout]]
*[[Customizing Moodle]]
*[[Administrator do's and don'ts]]
*[http://download.moodle.org/docs/using_moodle/ch16_server_admin.pdf Using Moodle Chapter 16: Moodle Administration]

[[Category: Administrator]]
[[cs:Rukověť správce]]
[[es:Documentación para Administradores]]
[[eu:Kudeatzaileentzako dokumentazioa]]
[[fr:Documentation administrateur]]
[[ja:管理者ドキュメント]]
[[ko:관리자 문서]]
[[nl:Documentatie voor beheerders]]
[[pt:Documentação para administradores]]
[[ru:Администраторам]]
[[zh:管理员文档]]
[[pl:Administrator documentation]]

Development:Output functions

2008-01-05T21:38:58Z

Szymonk: added inter-language link to polish wiki

This page tries to explain a bit how dynamic data should be sent from Moodle to the browser in an organised and standard way. Obviously it's possible to have your own output methods but, thinking that you are going to share your code (yep, this is an OpenSource project!) and in the collaborative way we try to build and maintain the system every day, it would be really better to follow the basic guidelines explained below.

By using them you will be helping to have better, more secure and readable code. Spend some minutes trying to understand them, please!

Of course, these functions can be discussed, modified and new functions can arrive if there are some good reasons for it. Just discuss it in the [http://moodle.org/mod/forum/view.php?id=55 General developer forum] at [http://moodle.org moodle.org].

For each of the functions below we'll try to explain when they should be used, explaining the most important parameters supported and their meaning. Let's review them!

=== p() and s() ===

function s($var, $strip=false)
function p($var, $strip=false)

These functions share the same code so they will be explained together. The only difference is that s() returns the string while p() prints it directly.

These functions should be used to:

* print all the '''values of form fields''' like <nowiki><input></nowiki> or <nowiki><textarea></nowiki> tags.
* to '''show plain (non html) text''' that has been introduced by the user (search string, quiz responses...).
* in general, all the '''dynamic data, not being html''', that doesn't need to be cleaned nor processed by filters

It is important not to use these functions for strings that contain html markup.

The functions replace certain characters that would have special meaning in html ( <, >, ", ', and &) by html entities so that they are displayed as intended. Note that even though the value of form fields printed with p() will have these characters converted to html entities, the submitted values will contain the original characters again.

The key parameter for this function is:

* '''strip''': it decides if we want to strip slashes from the string or no. By default it's 'false' so no strip will be performed. We should set such parameter to 'true' only when data to be processed isn't coming from database but from http requests (forms, links...).

=== format_text() ===

function format_text($text, $format=FORMAT_MOODLE, $options=NULL, $courseid=NULL )

This function should be used to:

* print '''any html/plain/markdown/moodle text''', needing any of the features below. Mainly used for long strings like posts, answers, glossary items...

Note that this function is really '''heavy''' because it supports '''cleaning''' of dangerous contents, delegates processing to enabled '''filter'''s, supports different '''formats''' of text (HTML, PLAIN, MARKDOWN, MOODLE) and performs a lot of '''automatic conversions''' like adding smilies, build links. Also, it includes a strong '''cache mechanism''' (DB based) that will alleviate the server from a lot of work processing the same texts time and again.

Some interesting parameters for this function are:

* '''format''': To tell the function about how the data has been entered. It defaults to FORMAT_MOODLE that is a cool format to process plain text because it features automatic link conversion, smilies and good conversion to html output. Other formats are FORMAT_HTML, FORMAT_PLAIN, FORMAT_MARKDOWN. See [[Formatting options]].

* '''options''': Here we can specify how we want the process to be performed. You only need to define them if they are different from the default value assumed. Main options are:
**'''options->noclean''': To decide if we want to skip the clean of text, '''un-protecting us''' from attacks and other security flaws (defaults to false, so protection is enabled. You '''shouldn't set it to true ever''' unless you are 200% sure that only controlled users can edit it (mainly admins). '''Never use it for general text places''' (posts...) or you will be, sooner or later, attacked! Note that this option is ignored for FORMAT_PLAIN, the text is never cleaned.
**'''options->filter''': To decide if you want to allow filters to process the text (defaults to true). This is ignored by FORMAT_PLAIN for which filters are never applied.
**'''options->smiley''': To decide if we want automatic conversion of smilies to images (defaults to true). This is ignored by FORMAT_PLAIN for which smileys are never converted.
**'''options->para''': To decide if you want every paragraph automatically enclosed between html paragraph tags (<nowiki><p>...</p></nowiki>) (defaults to true). This option only applies to FORMAT_MOODLE.
**'''options->newlines''': To decide if linefeeds in text should be converted to html newlines (<nowiki><br /></nowiki>) (defaults to true). This option only applies to FORMAT_MOODLE.
* '''courseid''': This parameter should be passed always to help filters to know how they should work. This parameter will become less and less important Moodle was 100% of the current course using some session or global variable (it's one work in progress just now) but, for now, it's recommended to set it always in the function call.

=== format_string() ===

function format_string ($string, $striplinks = true, $courseid=NULL )

This function should be used to:

* print '''short strings (non html) that need filter processing''' (activity titles, post subjects, glossary concepts...).

Please note that this function is basically one stripped version of the full format_text() function detailed above and '''it doesn't offer any of its options or protections'''. It simply filters the strings and returns the result, so we must ensure that text being processed has been properly cleaned at input time, using the proper xxx_param() functions.

Some interesting parameters for this function are:

* '''striplinks''': To decide if, after the text has been processed by filters, we must delete any link from the result text. Used when we want to show the text inside menus, page titles... (defaults to true).
* '''courseid''': This parameter should be passed always to help filters to know how they should work. This parameter will become less and less important Moodle was 100% of the current course using some session or global variable (it's one work in progress just now) but, for now, it's recommended to set it always in the function call.

=== print_textarea() ===

function print_textarea($usehtmleditor, $rows, $cols, $width,
$height, $name, $value=<nowiki>''</nowiki>, $courseid=0, $return=false)

This function should be used to:

* display <nowiki><textarea></nowiki> fields when we want to allow users (based in their preferences and browser capabilities) '''to use the visual HTML editor''' instead of one standard 'plain' area.

Some interesting parameters for this function are:

* '''usehtmleditor''': to decide if the HTML editor must be showed. The value of this parameter must be calculated by the can_use_html_editor() function.
* '''rows, cols''': to be applied it the standard textarea is showed.
* '''width, height''': to be applied if the HTML editor is used.
* '''name''': the name of the field that will contain the text once the form is submitted.
* '''value''': the initial value of the textarea.
* '''courseid''': This parameter should be passed always to help the editor to know where it is work. This parameter will become less and less important Moodle was 100% of the current course using some session or global variable (it's one work in progress just now) but, for now, it's recommended to set it always in the function call.
* '''return''': to decide if the generated html code must be returned to the caller (true) or printed directly (false). Defaults to false.

[[pl:Funkcje wyjściowe]]

[[Category:Developer|Output functions]]

Development:Coding

2008-01-05T14:35:59Z

Szymonk:

Any collaborative project needs consistency and stability to stay strong.

These '''coding guidelines''' are to provide a goal for all Moodle code to strive to. It's true that some of the older existing code falls short in a few areas, but it will all be fixed eventually. All new code definitely must adhere to these standards as closely as possible.

==General rules==

# All code files should use the .php extension.
# All template files should use the .html extension.
# All text files should use Unix-style text format (most text editors have this as an option).
# All php tags must be 'full' tags like <?php ?> ... not 'short' tags like <? ?>.
# All existing copyright notices must be retained. You can add your own if necessary.
# Each file should include (require_once) the main config.php file.
# Any other include/require should use an absolute path beginning with $CFG->dirroot or $CFG->libdir, not relative includes, which [http://uk.php.net/manual/en/function.include.php sometimes behave strangely under PHP].
# Each file should check that the user is authenticated correctly, using require_login() and has_capability() or require_capability().
# All access to databases should use the functions in ''lib/dmllib.php'' whenever possible - this allows compatibility across a wide range of databases. You should find that almost anything is possible using these functions. If you must write SQL code then make sure it is: cross-platform; restricted to specific functions within your code (usually a lib.php file); and clearly marked.
# Don't create or use global variables except for the standard $CFG, $SESSION, $THEME, $SITE, $COURSE and $USER.
# All variables should be initialised or at least tested for existence using isset() or empty() before they are used.
# All strings should be translatable - create new texts in the "lang/en_utf8" files with concise English lowercase names and retrieve them from your code using get_string() or print_string(). Never delete strings to ensure backwards compatibility of the language packs is maintained.
# All errors should be printed using print_error() to maximise translation and help for users (it automatically links to the docs wiki).
# All help files should be translatable - create new texts in the "lang/en_utf8/help" directory and call them using helpbutton(). If you need to update a help file:
#* with a minor change, where an old translation of the file would still make sense, then it's OK to make the change but you should notify translation AT moodle DOT org.
#* for a major change you should create a new file by adding an incrementing number (eg filename2.html) so that translators can easily see it's a new version of the file. Obviously the new code and the help index files should also be modified to point to the newest versions.
# Incoming data from the browser (sent via GET or POST) automatically has magic_quotes applied (regardless of the PHP settings) so that you can safely insert it straight into the database. All other raw data (from files, or from databases) must be escaped with addslashes() before inserting it into the database. Because this is so often done incorrectly, there is more explanation on this issue of adding and stripping slashes on a [[Developer:Slashes|separate page]].
# VERY IMPORTANT: All texts within Moodle, especially those that have come from users, should be printed using the format_text() function. This ensures that text is filtered and cleaned correctly. More information can be found on the page about [[Development:Output_functions|output functions]].
# User actions should be logged using the [[Development:Logs|add_to_log()]] function. These logs are used for [[Settings#Show_activity_reports|activity reports]] and [[Logs]].
# When generating a HTML link, always make it relative to the full site root, i.e. link to ''$CFG->wwwroot/mod/blonk/view.php?id=99'' rather than just ''view.php?id=99''. This means that your code will work if called by a script in another folder, among other things.

==Coding style==

I know it can be a little annoying to change your style if you're used to something else, but balance that annoyance against the annoyance of all the people trying later on to make sense of Moodle code with mixed styles. There are obviously many good points for and against any style that people use, but the current style just is, so please stick to it.

1. Indenting should be consistently 4 spaces. Don't use tabs AT ALL.

2. Variable names should always be easy-to-read, meaningful lowercase English words. If you really need more than one word then run them together, but keep them short as possible. Use plural names for arrays of objects.

GOOD: $quiz
GOOD: $errorstring
GOOD: $assignments (for an array of objects)
GOOD: $i (but only in little loops)

BAD: $Quiz
BAD: $aReallyLongVariableNameWithoutAGoodReason
BAD: $error_string

3. Constants should always be in upper case, and always start with the name of the module. They should have words separated by underscores.

define("FORUM_MODE_FLATOLDEST", 1);
4. Function names should be simple English lowercase words, and start with the name of the module to avoid conflicts between modules. Words should be separated by underscores. Parameters should always have sensible defaults if possible. Note there is no space between the function name and the following (brackets).

function forum_set_display_mode($mode=0) {
global $USER, $CFG;

if ($mode) {
$USER->mode = $mode;
} else if (empty($USER->mode)) {
$USER->mode = $CFG->forum_displaymode;
}
}

5. Blocks must always be enclosed in curly braces (even if there is only one line). Moodle uses this style:

if ($quiz->attempts) {
if ($numattempts > $quiz->attempts) {
error($strtoomanyattempts, "view.php?id=$cm->id");
}
}

6. Strings should be defined using single quotes where possible, so that [http://php.net/types.string less memory is used].

$var = 'some text without any variables';
$var = 'with special characters like a new line '."\n";
$var = 'a very, very long string with a '.$single.' variable in it';
$var = 'some '.$text.' with '.$many.' variables '.$within.' it';

7. Comments should be added as much as is practical, to explain the code flow and the purpose of functions and variables.

* Every function (and class) should use the popular [http://www.phpdoc.org/ phpDoc format]. This allows code documentation to be generated automatically.
* Inline comments should use the // style, laid out neatly so that it fits among the code and lines up with it.

/**
* The description should be first, with asterisks laid out exactly
* like this example. If you want to refer to a another function,
* do it like this: {@link clean_param()}. Then, add descriptions
* for each parameter as follows.
*
* @param int $postid The PHP type is followed by the variable name
* @param array $scale The PHP type is followed by the variable name
* @param array $ratings The PHP type is followed by the variable name
* @return mixed
*/
function forum_get_ratings_mean($postid, $scale, $ratings=NULL) {
if (!$ratings) {
$ratings = array(); // Initialize the empty array
if ($rates = get_records("forum_ratings", "post", $postid)) {
// Process each rating in turn
foreach ($rates as $rate) {
....etc

8. Space should be used liberally - don't be afraid to spread things out a little to gain some clarity. Generally, there should be one space between brackets and normal statements, but no space between brackets and variables or functions:

foreach ($objects as $key => $thing) {
process($thing);
}

if ($x == $y) {
$a = $b;
} else if ($x == $z) {
$a = $c;
} else {
$a = $d;
}

9. When making a COPY of an object, always use the php5 clone() function (otherwise you may end up with just a reference to the first object). Moodle will make sure this works consistently on php4 too.

BAD: $b = $a;
GOOD: $b = clone($a);

If the thing you want to copy is not an object, but may contain objects (eg an array of objects) then use fullclone() instead.

==Database structures==

To help you create tables that meet these guidelines, we recommend you use the built in [[Development:XMLDB_defining_an_XML_structure#The_XMLDB_editor|database definition (XMLDB) editor]].

# Every table must have an auto-incrementing id field (INT10) as primary index. (see [[IdColumnReasons]])
# The main table containing instances of each module must have the same name as the module (eg widget) and contain the following minimum fields:
#* id - as described above
#* course - the id of the course that each instance belongs to
#* name - the full name of each instance of the module
# Other tables associated with a module that contain information about 'things' should be named widget_things (note the plural).
# Table and column names should avoid using [[Database reserved words|reserved words in any database]]. Please check them before creation.
# Column names should be always lowercase, simple and short, following the same rules as for variable names.
# Where possible, columns that contain a reference to the id field of another table (eg widget) should be called widgetid. (Note that this convention is newish and not followed in some older tables)
# Boolean fields should be implemented as small integer fields (eg INT4) containing 0 or 1, to allow for later expansion of values if necessary.
# Most tables should have a timemodified field (INT10) which is updated with a current timestamp obtained with the PHP time() function.
# Always define a default value for each field (and make it sensible)
# Each table name should start with the database prefix ($CFG->prefix). In a lot of cases, this is taken care of for you automatically. Also, under Postgres, the name of every index must start with the prefix too.
# In order to guarantee [[Development:XMLDB problems#Table and column aliases - the AS keyword|cross-db compatibility]] follow these simple rules about the use of the '''AS''' keyword (only if you need table/colum aliases, of course):
#* '''Don't use''' the '''AS''' keyword for '''table aliases'''.
#* '''Do use''' the '''AS''' keyword for '''column aliases'''.
# '''Never''' create UNIQUE KEYs (constraints) at all. Instead use UNIQUE INDEXes. In the future, if we decide to add referential integrity to Moodle and we need UNIQUE KEYs they will be used, but not now. Please note that the XMLDB editor allows you to specify both XMLDB-only UNIQUE and FOREIGN constraints (and that's good, in order to have the XML well defined) but only underlying INDEXes will be generated.
# Those XMLDB-only UNIQUE KEYs (read previous point) only must be defined if such field/fields '''are going to be the target''' for some (XMLDB-only too) FOREIGN KEY. Else, create them as simple UNIQUE INDEXes.
# Tables associated '''with one block''' must follow this convention with their names: '''$CFG->prefix + "block_" + name_of_the_block + anything_else'''. For example, assuming that $CFG->prefix is 'mdl_', all the tables for the block "rss_client" must start by 'mdl_block_rss_client' (being possible to add more words at the end, i.e. 'mdl_block_rss_client_anothertable'...). This rule will be 100% enforced with Moodle 2.0, giving time to developers until then. See [http://tracker.moodle.org/browse/MDL-6786 Task 6786] for more info about this.
# '''Never''' make database changes in the STABLE branches. If we did, then users upgrading from one stable version to the next would have duplicate changes occurring, which may cause serious errors.
# When refering to integer variable in SQL queries, do not surround the value in quotes. For example, get_records_select('question', "category=$catid") is right. get_records_select('question', "category='$catid'") is wrong. It hides bugs where $catid is undefined. ([http://moodle.org/mod/forum/discuss.php?d=80629 This thread explains].)

==Security issues (and handling form and URL data)==

# Do not rely on 'register_globals'. Every variable must be properly initialised in every code file. It must be obvious where the variable came from.
# Initialise all arrays and objects, even if empty. $a = array() or $obj = new stdClass();.
# Do not use the optional_variable() function (this function is now deprecated). Use the optional_param() function instead. Pick the correct PARAM_XXXX value for the data type you expect.
# Do not use the require_variable() function (this function is now deprecated). Use the required_param() function instead. Pick the correct PARAM_XXXX value for the data type you expect.
# Use data_submitted(), with care. Data must still be cleaned before use.
# Do not use $_GET, $_POST or $_REQUEST. Use the appropriate required_param() or optional_param() appropriate to your need.
# Do not check for an action using something like if (isset($_GET['something'])). Use, e.g., $something = optional_param( 'something',-1,PARAM_INT ) and then perform proper test for it being in its expected range of values e.g., if ($something>=0) {....
# Wherever possible group all your required_param(), optional_param() and other variables initialisation at the beginning of each file to make them easy to find.
# Use 'sesskey' mechanism to protect form handling routines from attack. Basic example of use: when form is generated, include <input type="hidden" name="sesskey" value="<?php echo sesskey(); ?>" />. When you process the form check with if (!confirm_sesskey()) {error('Bad Session Key');}.
# All filenames must be 'cleaned' using the clean_filename() function, if this has not been done already by appropriate use of required_param() or optional_param()
# Any data read from the database must have [[Developer:Slashes|addslashes()]] applied to it before it can be written back. A whole object of data can be hit at once with addslashes_object().
# Wherever possible, data to be stored in the database must come from POST data (from a form with method="POST") as opposed to GET data (ie, data from the URL line).
# Do not use data from $_SERVER if you can avoid it. This has portability issues.
# If it hasn't been done somewhere else, make sure all data written to the database has been through the clean_param() function using the appropriate PARAM_XXXX for the datatype.
# If you write custom SQL code, make very sure it is correct. In particular watch out for missing quotes around values. Possible SQL 'injection' exploit.
# Check all data (particularly that written to the database) in every file it is used. Do not expect or rely on it being done somewhere else.
# Blocks of code to be included should contain a definite PHP structure (e.g, a class declaration, function definition(s) etc.) - straight blocks of code promote uninitialised variable usage.

[[Category:Developer|Coding]]

[[es:Manual de Estilo de Código]]
[[ja:コーディング]]
[[zh:代码指南]]
[[pl:Kodowanie]]

Development:Developer FAQ

2008-01-05T14:32:51Z

Szymonk:

{{FAQ}}

==Help for new coders==

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

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

==Moodle's database==

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

When installing Moodle, the database tables are generated and updated by various db-handling scripts located in various places. There is no canonical schema representation, although the [[Coding#Database_structures | coding guidelines for database structure]] give an outline of the general approach.

The reason that the database information isn't stored in one place is because of Moodle's '''modular structure'''. Each activity module, for example, comes as a folder with script files inside. If the module needs to store information in the database, it must include scripts in a "db" subfolder which define and update the database structure.

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

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

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

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

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

Always use the "datalib" functions, such as insert_record() or get_record(). Since Moodle 1.7 these are found in lib/dmllib.php. Using these functions helps with database abstraction (e.g. running on either MySQL or Postgres) as well as maintaining a single database connection. Moodle uses ADODB for database abstraction.

Look at [http://phpdocs.moodle.org/moodlecore/_lib---datalib.php.html the documentation for datalib.php] for the list of functions and details of use.

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

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

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

==See also==

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

[[Category: Developer]]
[[Category: FAQ]]

[[es:FAQ Desarrollador]]
[[fr:FAQ de développement]]
[[pl:Developer FAQ]]

Category:FAQ

2008-01-05T14:32:02Z

Szymonk:

An FAQ is a list of Frequently Asked Questions, along with their answers.

==Other sources of help==

If you can't find the answer to your question in one of FAQ pages listed below, please try

* [[MoodleDocs:Searching|Searching Moodle Docs]]
* Browsing the moodle.org [http://moodle.org/course/view.php?id=5 Using Moodle course]

[[Category:Teacher]]
[[Category:Administrator]]
[[Category:Developer]]

[[fr:Catégorie:FAQ]]
[[pl:Kategoria:FAQ]]

PHP info

2008-01-05T13:38:37Z

Szymonk:

Location: ''Administration > Server > 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.
* that you have installed the required modules needed for Moodle to work, e.g. the LDAP module for LDAP authentication.

==Displaying phpinfo==
To view the phpinfo information:
* In Moodle version 1.7 or greater, choose Site Administration -> Server -> PHP info.
* Create a file called info.php using your text editor, containing this single line:

<?php phpinfo(); ?>

==Sample output==
This is a sample output displayed:

<table border="0" cellpadding="3" width="600">
<tr class="h"><td>
[http://www.php.net/ http://www.php.net]
=PHP Version 4.3.3=
</td></tr>
</table><br/>
<table border="0" cellpadding="3" width="600">
<tr><td class="e">System </td><td class="v">Windows NT MYLAPTOP0106 5.1 build 2600 </td></tr>
<tr><td class="e">Build Date </td><td class="v">Aug 24 2003 22:01:16 </td></tr>
<tr><td class="e">Server API </td><td class="v">Apache </td></tr>
<tr><td class="e">Virtual Directory Support </td><td class="v">enabled </td></tr>
<tr><td class="e">Configuration File (php.ini) Path </td><td class="v">C:\WINDOWS\php.ini </td></tr>
<tr><td class="e">PHP API </td><td>20020918 </td></tr>
<tr><td class="e">PHP Extension </td><td>20020429 </td></tr>
<tr><td class="e">Zend Extension </td><td>20021010 </td></tr>
<tr><td class="e">Debug Build </td><td>no </td></tr>
<tr><td class="e">Thread Safety </td><td>enabled </td></tr>
<tr><td class="e">Registered PHP Streams </td><td>php, http, ftp, compress.zlib</td></tr>
</table>

...
This output goes on for about 5 pages.

[[es:phpinfo]]
[[pt:phpinfo]]
[[pl:phpinfo]]

[[Category:Developer|Phpinfo]]
[[Category:Administrator]]

PHP info

2008-01-05T13:37:15Z

Szymonk: added inter-language link to polish wiki

Location: ''Administration > Server > 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.
* that you have installed the required modules needed for Moodle to work, e.g. the LDAP module for LDAP authentication.

==Displaying phpinfo==
To view the phpinfo information:
* In Moodle version 1.7 or greater, choose Site Administration -> Server -> PHP info.
* Create a file called info.php using your text editor, containing this single line:

<?php phpinfo(); ?>

==Sample output==
This is a sample output displayed:

<table border="0" cellpadding="3" width="600">
<tr class="h"><td>
[http://www.php.net/ http://www.php.net]
=PHP Version 4.3.3=
</td></tr>
</table><br/>
<table border="0" cellpadding="3" width="600">
<tr><td class="e">System </td><td class="v">Windows NT MYLAPTOP0106 5.1 build 2600 </td></tr>
<tr><td class="e">Build Date </td><td class="v">Aug 24 2003 22:01:16 </td></tr>
<tr><td class="e">Server API </td><td class="v">Apache </td></tr>
<tr><td class="e">Virtual Directory Support </td><td class="v">enabled </td></tr>
<tr><td class="e">Configuration File (php.ini) Path </td><td class="v">C:\WINDOWS\php.ini </td></tr>
<tr><td class="e">PHP API </td><td>20020918 </td></tr>
<tr><td class="e">PHP Extension </td><td>20020429 </td></tr>
<tr><td class="e">Zend Extension </td><td>20021010 </td></tr>
<tr><td class="e">Debug Build </td><td>no </td></tr>
<tr><td class="e">Thread Safety </td><td>enabled </td></tr>
<tr><td class="e">Registered PHP Streams </td><td>php, http, ftp, compress.zlib</td></tr>
</table>

...
This output goes on for about 5 pages.

[[es:phpinfo]]
[[pl:phpinfo]]
[[pt:phpinfo]]

[[Category:Developer|Phpinfo]]
[[Category:Administrator]]