MoodleDocs - User contributions [en]

Question behaviours

2021-04-22T03:56:50Z

Battya: /* How questions behave */ Bolded the requirement for "Interactive with multiple tries" of having something in the "multiple tries" hint text boxes.

{{Questions}}
==How questions behave==
The following question behaviours are available when [[Quiz settings|creating a quiz]] (also when previewing questions):

;Deferred feedback
:Students must enter an answer to each question and then submit the entire quiz, before anything is graded or they get any feedback.
;Adaptive mode and Adaptive mode (no penalties)
:Allows students to have multiple attempts at the question before moving on to the next question. This behaviour requires that the "Whether correct" box is ticked under "During the attempt" in the "Review options" section, at a minimum.
;Manual grading
:Used for [[Essay question type|essay questions]] (irrespective of what the quiz is set to) but you can now choose to have every question in the quiz manually graded, if you wish.
;Interactive with multiple tries
:Used for allowing multiple attempts on the same question (perhaps with a grade penalty). Students answer the question and click the 'Check' button. If the answer is wrong, the student can click the 'Try again' button to try a new response. '''Importantly, the question definition must contain hints that will be shown after each incorrect attempt, though the hint text can be as minimal as an HTML non-breaking space.''' Once the student has got the question right, they can no longer change their response. Once the student has got the question wrong too many times, they are just graded wrong (or partially correct) and get shown the feedback. Unless 'Allow redo within an attempt' was enabled in the '[[Quiz_settings#Question_behaviour|Question behaviour]]' settings of the quiz, they can no longer change their answer. There can be specific feedback after each try the student makes, in addition to overall feedback about incorrect or correct answers and answer choices. The number of tries the student gets is the number of hints in the question definition plus one, with a minimum of three.
;Immediate feedback
:Similar to interactive mode in that the student can submit their response immediately during the quiz attempt, and get it graded. However, they can only submit one response, they cannot change it later.
;Deferred feedback or Immediate feedback with Certainty-based marking (CBM)
:With CBM, the student does not only answer the question, but they also indicate how sure they are they got the question right. The grading is adjusted by the choice of certainty, so that students have to reflect honestly on their own level of knowledge in order to get the best mark.
;Conditional questions
:If using the Interactive with multiple tries or Immediate Feedback behaviour and with the navigation method set to 'Free', it is possible to make the display of a question dependent on a previous question being answered first.
:The question editing page will display padlock icons to the right of each question.

==Certainty-based marking==
When a student answers a question they also have to state how sure they are of the answer: not very (less than 67%); fairly (more than 67%) or very (more than 80%). Their grading is then adjusted according to how certain they are, which means that for example if they answered correctly but were only guessing, their mark is adjusted from 1 to 0.33. If they answered wrongly but were very sure, their mark is adjusted from 0 to -2.

For detailed information on how CBM works and how students can benefit from it, see [[Using certainty-based marking]].
{|
| [[File:cbm03.png|thumb|correct answer; very sure]]
| [[File:cbm05.png|thumb|correct answer; fairly sure]]
| [[File:cmb04.png|thumb|correct answer; not very sure]]
| [[File:cbm01.png|thumb|wrong answer; very sure]]
| [[File:cbm99.png|thumb|wrong answer; not very sure]]
|}

==Managing question behaviours==

An administrator can manage question behaviours available across the site in ''Administration > Site administration > Plugins > Question behaviours > Manage question behaviours''.

==Deferred feedback with explanation==
[https://moodle.org/plugins/view.php?plugin=qbehaviour_deferredfeedbackexplain Deferred feedback with explanation] is an additional question behaviour, available for Moodle 2.6+, that is just like deferred feedback, but with an additional input box where students can give a reason why they gave the answer they did. No attempt is made to automatically grade the explanation, nor is it required.
* It may be used in various ways, for example:
** The teacher may want to manually edit the grades where the student gave a wrong answer, to give partial credit if the student used the right method or approach.
** The student might want to explain their thinking, so that later, when the results and feedback are revealed, they are reminded of what they were thinking at the time, and so can reflect more deeply.
* You can use [[Language customization]] to change the default text string "Explain your reasons" in the file qbehaviour_deferredfeedbackexplain.php to a more specific text such as "Enter justifications below if you want partial credit in numerical problems by showing your steps, ignore otherwise." as described in https://moodle.org/mod/forum/discuss.php?d=275752

==Interactive with explanation==
[[qbehaviour interactiveexplain]] is an additional question behaviour, available for Moodle 3.x, that is based heavily on Tim Hunts deferred feedback with explanation question behaviour. This behaviour is like the interactive with multiple attempts behaviour, but with an additional text box where students can give a reason why they gave the answer they did. No attempt is made to automatically grade the explanation, nor is it required. The code can be found at https://github.com/marcusgreen/moodle-qbehaviour_interactiveexplain

==See also==

* [http://www.ucl.ac.uk/lapt/ LAPT: UCL home of Certainty-Based Marking]
* [https://moodle.org/mod/forum/discuss.php?d=225920 CBM too harsh?] forum discussion
* [http://school.moodledemo.net/mod/quiz/view.php?id=1496 School demo example of a quiz with CBM] Log into with username "parent" and password "moodle"
* [http://helderenwijzer.nl/2011/10/certainty-based-marking-in-moodle/ Certainty Based Marking in Moodle] blog post by Isabelle Langeveld
* [http://www.open.edu/openlearnworks/mod/oucontent/view.php?id=51788&section=6 Styles of interactive computer marked assessments] from the Open University
*[https://moodle.org/mod/forum/discuss.php?d=313947 This forum thread] about adding an 'all or nothing' behaviour for adaptive and deferred feedback for questions in a quiz.

[[Category:Site administration]]

[[de:Frageverhalten]]
[[es:Comportamientos de preguntas]]
[[fr:Comportement des questions]]

OPcache

2020-09-17T23:43:41Z

Battya: /* Linux, Mac OS and other Unix-like platforms */ Corrected "Mac OS" to "macOS," which is the official styling of the OS name for the past few years.

{{Environment}}

The standard OPcache extension is strongly recommended; since Moodle 2.6, it is the only solution officially supported by PHP developers. The benefits are increased performance and significantly lower memory usage. However, opcode caching extensions (including OPcache, eAccelerator and APC) aren't compatible with servers configured to use some common types of high-security PHP handlers such as suPHP (the default on WHM / cPanel Linux servers).

[[File:Opcache_error.png|800px]]

==Installation==

The OPcache extension is distributed as part of PHP 5.5 and later. It is available also for older stable PHP releases from PECL under the original name ZendOPcache. To check if the extension is loaded and enabled look at [[PHP#Displaying_phpinfo_in_Moodle|the PHP info page]] under the '''Zend OPcache''' heading.

===Linux, macOS and other Unix-like platforms===

You may need to install a specific package, e.g. on CentOS, Fedora or Red Hat: '''dnf install php-opcache'''. If necessary add the following to '''php.ini''' (package installers may do this automatically):
<code ini>
zend_extension=/full/path/to/opcache.so
</code>

===Microsoft Windows===

The extension '''php_opcache.dll''' is included in the '''ext''' folder in the [https://windows.php.net/download PHP for Windows binary downloads].
To enable it add the following to '''php.ini''':

<code ini>
zend_extension=php_opcache.dll
</code>

==Configuration==

'''php.ini''' settings:

<code ini>
[opcache]
opcache.enable = 1
opcache.memory_consumption = 128
opcache.max_accelerated_files = 10000
opcache.revalidate_freq = 60

; Required for Moodle
opcache.use_cwd = 1
opcache.validate_timestamps = 1
opcache.save_comments = 1
opcache.enable_file_override = 0

; If something does not work in Moodle
;opcache.revalidate_path = 1 ; May fix problems with include paths
;opcache.mmap_base = 0x20000000 ; (Windows only) fix OPcache crashes with event id 487

; Experimental for Moodle 2.6 and later
;opcache.fast_shutdown = 1
;opcache.enable_cli = 1 ; Speeds up CLI cron
;opcache.load_comments = 0 ; May lower memory use, might not be compatible with add-ons and other apps.
</code>

; memory_consumption
From: [http://blog.jpauli.tech/2015-03-05-opcache-html/ PHP's OPCache extension review]
*''The size of the memory segment can be told using the opcache.memory_consumption INI setting (Megabytes). Size it big, don't hesitate to give space. Never ever run out of shared memory space, if you do, you will lock your processes, we'll get back to that later.''

*''Size the shared memory segment according to your needs, don't forget that a production server dedicated to PHP processes may bundle several dozens of Gigabytes of memory, just for PHP. Having a 1Gb shared memory segment (or more) is not uncommon, it will depend on your needs, but if you use a modern application stack, aka framework based, with lots of dependencies etc... , then use at least 1Gb of shared memory.''

Having that in mind, set opcache.memory_consumption to a value high enough to avoid filling it up (as long as your RAM usage allows you to), and then monitor the OPCache to adjust that value to its optimal size. As the total size of the PHP files in a standard Moodle 3.6 is almost 90MB, setting this value higher than that can be a good idea. Take into account that the PHP files of the plugins and those on the MoodleData folder (language pack files...) also count, so these values can be different on each installation. If you have several instances of Moodle you should multiply that value by the number of instances.

Tip: If using Linux, you can know the total size of the PHP files of a folder using this command:
<code ini>
find ./ -type f -name "*.php" -printf "%s\n" | gawk -M '{t+=$1}END{print t}' | numfmt --to=iec
</code>

; max_accelerated_files
From: [http://php.net/manual/en/opcache.configuration.php#ini.opcache.max-accelerated-files php.net max-accelerated-files]
*''The maximum number of keys (and therefore scripts) in the OPcache hash table. The actual value used will be the first number in the set of prime numbers { 223, 463, 983, 1979, 3907, 7963, 16229, 32531, 65407, 130987 } that is greater than or equal to the configured value. The minimum value is 200. The maximum value is 100000 in PHP < 5.5.6, and 1000000 in later versions.''

As Moodle 3.6 contains almost 10.000 php files it is recommended above that opcache.max_accelerated_files should be set to 10000 to accommodate this (16229 will actually be used as per the explanation above). If you have several instances of Moodle you should multiply that value by the number of instances.

If many additional plugins are installed so that your total PHP files exceed 16229 then the next most suitable value for max_accelerated_files should be used.
Tip: If using Linux, you can know the total PHP files of your Moodle using this command:
<code ini>
find ./ -type f | grep -E ".*\.php$" | sed -e 's/.*$\.[a-zA-Z0-9]*$$/\1/' | sort | uniq -c | sort -n
</code>

==Opcache management plugin==
[[File:Opcache_management_message.png|400px]]

You may consider installing the additional [https://moodle.org/plugins/tool_opcache Opcache management] - Moodle plugin which adds a PHP Opcache management GUI to Moodle site administration, a CLI tool to reset PHP Opcache and a Nagios check for PHP Opcache.

[[File:Opcache management status.png|800px]]

==See also==
* [http://pecl.php.net/package/ZendOpcache PECL ZendOPcache]

Forum discussions:
* [https://moodle.org/mod/forum/discuss.php?d=244133 OPcache: Memory Usage = 100% (is this good or bad?)]
* [https://moodle.org/mod/forum/discuss.php?d=245885 OPCode cache]

[[Category:Environment]]
[[Category:Installation]]
[[Category:Performance]]

[[es:OPcache]]

Site backup

2020-09-12T00:55:16Z

Battya: Updated the AutoMySQLBackup URL to the actively-maintained fork on GitHub, as the original developer has handed it off.

{{Backup}}
A site backup allows a site administrator to save everything associated with a moodle site. These backups can be restored to bring a site back to the point in time when the backup was made.

Performing regular backups are highly recommended to reduce the amount of lost information in the event of a problem on the site and to speed the overall recovery process.

== What needs to be backed up? ==

A Moodle system comprises three parts:
# The data stored in the database (For example, a MySQL database)
# The uploaded files (For example, site and course files uploaded via Moodle located in moodledata)
# The '''Moodle code''' (For example, everything in server/htdocs/moodle)
You can confirm where all these things are located in a Moodle installation by checking the '''[[Configuration file|config.php]]''' file.

:# '''$CFG->dbname''' shows the database name
:# '''$CFG->prefix''' shows the the database table name prefix
:# '''$CFG->dataroot''' controls where the ''uploaded files'' are stored; and
:# '''$CFG->wwwroot''' points to where the ''code'' is stored.

;Tip
Generally speaking, the database ("dbname and prefix") and the uploaded files (dataroot) are the two most important to copy on a regular basis. These contain information that will change most often.

The Moodle code (wwwroot) is less important as a frequent backup, since it will only change when the the actual code is changed through upgrades, addins and code tweaks. You can always get a copy of the standard Moodle code from http://download.moodle.org so you only have to backup the parts you added or changed yourself.

== Creating a backup of your Moodle site ==

=== Database ===

The right way to back up your database depends on which database system you are using. The instructions below are one way to back up a MySQL database. Another option would be to use a tool like phpMyAdmin to manually make a backup. The documentation for your database will give more options.

There are many ways to do such backups. Here is an outline of a little script you can run on Unix to backup the database (it works well to have such a script run daily via a cron task):

cd /my/backup/directory
mv moodle-database.sql.gz moodle-database-old.sql.gz
mysqldump -h example.com -u myusername --password=mypassword -C -Q -e --create-options mydatabasename > moodle-database.sql
gzip moodle-database.sql

Also consider using an option to help ensure that the backup is consistent (e.g. avoid the data changing half-way through the backup), e.g. for MySQL/MariaDB and mysqldump try [https://dev.mysql.com/doc/refman/5.7/en/mysqldump.html#option_mysqldump_single-transaction --single-transaction].

==== Character encoding ====
Make sure that a database backup uses the correct character encoding. In most databases, use [[UTF-8]].

When dumping the entire Moodle database, check for possible character encoding issues. In some instances, backups created with [http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html mysqldump] or [http://www.phpmyadmin.net phpMyAdmin] may not properly encode all of the data. This will result in non-readable characters when the database is restored.

:''Tip'': One solution is to use MySQL Administrator 1.1 or another tool that will force a UTF-8 dump of the data.

==== Tools for database backups ====

; phpMyAdmin
: [http://www.phpmyadmin.net phpMyAdmin] is the tool of choice with most web hosting providers.

; MySQLDumper
: [https://sourceforge.net/projects/mysqldumper/ MySQLDumper] is a backup script for MySQL databases, written in PHP and Perl. MySQLDumper uses a proprietary technique to avoid execution interruption when running PHP scripts (the max. execution time is usually set to 30 seconds). MySQLDumper also cares for the encoding problems mentioned above. It also works with compressed files and allows setting up regular cron jobs for updating and updating to a remote FTP site.

; AutoMySQLBackup
: [https://github.com/sixhop/AutoMySQLBackup AutoMySQLBackup] is a backup script for MySQL databases, written in PHP. AutoMySQLBackup will create Daily, Weekly and Monthly backups of one or more of your MySQL databases from one or more of your MySQL servers. Features include email notification, compression and encryption, configurable backup rotation, incremental database backups, and more.

=== Uploaded files (moodledata) ===
Through the Moodle interface, users can upload or create files and folders. These are located in a directory, often called "moodledata". Since they are just files and folders, there are many different ways to backup or copy moodledata.

* For example, using a file transfer program, copy the entire moodledata directory to a different area, drive or computer. Example of file transfer programs include: FTP, WinSP, wget, rsync.

* You might use a compression program to create compact files (tar, zip. 7z, XZ, BZIP2, GZIP, and WIM are a few file formats) of the entire directory. This can be done before or after file transfers.

; Tips
* Typically not all moodledata files change between regular/periodic backups. A new Administrator might want to look into [http://en.wikipedia.org/wiki/Incremental_backup incremental or other efficient backups] procedures.
* Depending upon the operating environment there are many tools for backing up server files and ways of backing up moodledata. See [[Tools_for_backing_up_server_files]] for tips on using rsync, FTP or Wget.

=== Moodle code ===
Backing up the Moodle code, will be similar to backing up moodledata. See [[Tools for backing up server files]].

;Tip
It is always a good idea to have several backup copies of your Moodle code files. While you can always download a fresh base copy of the Moodle code from http://download.moodle.org, you might have customized that code. It is a good idea to create a separate backup of your Moodle code before you customize the code. This includes installing [[Contributed code]], [[Themes]] and upgrading.

== See also ==
* [https://www.youtube.com/watch?v=k5rwTy3sNh0 Screencast: How to back up a Moodle site] (thanks to Bruce Chambr)
*[[Site restore]] Now that you have a backup, how to restore it
* [[Moodle migration]] - move a Moodle site to a different server
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=140949 Site DatabaseBackup Using phpMyAdmin] forum discussion
* [[Site Backup for Low-tech Users]]

[[de:Sicherung der Moodle-Installation]]
[[ja:サイトバックアップ]]
[[es:Copia de seguridad del sitio]]
[[fr:Sauvegarde de site]]

Cron with Unix or Linux

2020-08-14T08:14:27Z

Battya:

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

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

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

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

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

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

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

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

== Method 2: Web based cron ==

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

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

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

...OR...

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

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

Once you have selected (and tested!) an appropriate command to invoke the Moodle cron it must be added to the web users 'crontab' to schedule it to run regularly. 'Crontab' is both a file containing the user's cron commands and is also the name of the (command line) program used to edit it. Use the following command (as root) substituting the correct user in place of 'www-data' (e.g. 'apache' for Centos, 'www-data' for Debian/Ubuntu, '_www' for macOS—Google will know!)
<pre>
# crontab -u www-data -e
</pre>
This will bring up an editor window (the first time it may ask you which editor to use). Add the command onto the end of the file in this way (it may be empty or it may have some instructional comments):
<pre>
*/1 * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php >/dev/null
</pre>
The first five entries specify the times, followed by the command, to run. This says to run the command every minute which is normally ok. On a hosted system you may get complaints if you do not run it a lot less often (e.g. to run every two hours use '0 */2 * * *' for the first five entries). If you want to use the wget/curl version, the first five entries remain the same - just change the command part.

== High performance cron tasks ==

Each time cron is run, after the scheduled tasks the adhoc tasks are also run. But adhoc tasks can be queued at any moment, and generally you want them processed as soon as possible and to not have to wait for the scheduled task to run first. You can run one or more dedicated adhoc task processors:

<pre>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute >/dev/null
</pre>

Starting from Moodle 3.9 you can tell it to stay alive when the queue is empty waiting for new tasks:

<pre>
* * * * * /usr/bin/php /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59 >/dev/null
</pre>

If you have a very high low number of adhoc tasks, or scheduled tasks, you can also spawn multiple cron.php and adhoc_task.php processes to get more throughput. By default Moodle will make sure than no more than 3 processes run at any time, you can tune these limits as needed in Site administration > Server > Tasks > Task processing

== See also ==

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

[[es:Cron con Unix o Linux]]

OPcache

2020-08-14T06:42:33Z

Battya:

{{Environment}}

The standard OPcache extension is strongly recommended; since Moodle 2.6, it is the only solution officially supported by PHP developers. The benefits are increased performance and significantly lower memory usage. However, opcode caching extensions (including OPcache, eAccelerator and APC) aren't compatible with servers configured to use some common types of high-security PHP handlers such as suPHP (the default on WHM / cPanel Linux servers).

[[File:Opcache_error.png|800px]]

==Installation==

The OPcache extension is distributed as part of PHP 5.5.0 and later. It is available also for older stable PHP releases from PECL under the original name ZendOPcache.

'''NOTE: If you are running PHP 5.3 or 5.4 you can safely ignore the Environment Check message about OpCache. Nonetheless, [https://moodle.org/mod/forum/discuss.php?d=245885 it might be useful] to upgrade Operating System/PHP and get to 5.5 or newer; as there have been all sorts of problems described on PHP 5.2 and 5.3, and upgrading PHP turned out to be the easier solution. '''

==Configuration==
=== Windows ===
PHP.ini settings '''''for Windows''''' (see immediately below for normal environments):

<code ini>
[opcache]
zend_extension = php_opcache.dll
opcache.enable = 1
opcache.memory_consumption = 128
opcache.max_accelerated_files = 10000
opcache.revalidate_freq = 60

; Required for Moodle
opcache.use_cwd = 1
opcache.validate_timestamps = 1
opcache.save_comments = 1
opcache.enable_file_override = 0

; If something does not work in Moodle
;opcache.revalidate_path = 1 ; May fix problems with include paths
;opcache.mmap_base = 0x20000000 ; (Windows only) fix OPcache crashes with event id 487

; Experimental for Moodle 2.6 and later
;opcache.fast_shutdown = 1
;opcache.enable_cli = 1 ; Speeds up CLI cron
;opcache.load_comments = 0 ; May lower memory use, might not be compatible with add-ons and other apps.
</code>
=== Unix/Linux/macOS ===
When using '''''non-Windows''''' (i.e., normal Unix/Linux/macOS) platforms, you have to use the ''zend_extension'' configuration to load the OPcache extension into PHP by adding to php.ini.
<code ini>
zend_extension=/full/path/to/opcache.so
</code>
===IIS===
When using IIS you will need PHP 5.5 and you will need to add the extension for opcache under the ''ExtensionList'' section of the php.ini file. For PHP 5.3 and 5.4 you can download the binaries separately from [http://windows.php.net/downloads/pecl/releases/opcache] and you will also need to enter full absolute path to the module dll in php.ini.

<code ini>
[ExtensionList]
...
zend_extension=php_opcache.dll
</code>

; memory_consumption
From: [http://blog.jpauli.tech/2015-03-05-opcache-html/ PHP's OPCache extension review]
*''The size of the memory segment can be told using the opcache.memory_consumption INI setting (Megabytes). Size it big, don't hesitate to give space. Never ever run out of shared memory space, if you do, you will lock your processes, we'll get back to that later.''

*''Size the shared memory segment according to your needs, don't forget that a production server dedicated to PHP processes may bundle several dozens of Gigabytes of memory, just for PHP. Having a 1Gb shared memory segment (or more) is not uncommon, it will depend on your needs, but if you use a modern application stack, aka framework based, with lots of dependencies etc... , then use at least 1Gb of shared memory.''

Having that in mind, set opcache.memory_consumption to a value high enough to avoid filling it up (as long as your RAM usage allows you to), and then monitor the OPCache to adjust that value to its optimal size. As the total size of the PHP files in a standard Moodle 3.6 is almost 90MB, setting this value higher than that can be a good idea. Take into account that the PHP files of the plugins and those on the MoodleData folder (language pack files...) also count, so these values can be different on each installation. If you have several instances of Moodle you should multiply that value by the number of instances.

Tip: If using Linux, you can know the total size of the PHP files of a folder using this command:
<code ini>
find ./ -type f -name "*.php" -printf "%s\n" | gawk -M '{t+=$1}END{print t}' | numfmt --to=iec
</code>

; max_accelerated_files
From: [http://php.net/manual/en/opcache.configuration.php#ini.opcache.max-accelerated-files php.net max-accelerated-files]
*''The maximum number of keys (and therefore scripts) in the OPcache hash table. The actual value used will be the first number in the set of prime numbers { 223, 463, 983, 1979, 3907, 7963, 16229, 32531, 65407, 130987 } that is greater than or equal to the configured value. The minimum value is 200. The maximum value is 100000 in PHP < 5.5.6, and 1000000 in later versions.''

As Moodle 3.6 contains almost 10.000 php files it is recommended above that opcache.max_accelerated_files should be set to 10000 to accommodate this (16229 will actually be used as per the explanation above). If you have several instances of Moodle you should multiply that value by the number of instances.

If many additional plugins are installed so that your total PHP files exceed 16229 then the next most suitable value for max_accelerated_files should be used.
Tip: If using Linux, you can know the total PHP files of your Moodle using this command:
<code ini>
find ./ -type f | grep -E ".*\.php$" | sed -e 's/.*$\.[a-zA-Z0-9]*$$/\1/' | sort | uniq -c | sort -n
</code>

==Opcache management plugin==
[[File:Opcache_management_message.png|400px]]

You may consider installing the additional [https://moodle.org/plugins/tool_opcache Opcache management] - Moodle plugin which adds a PHP Opcache management GUI to Moodle site administration, a CLI tool to reset PHP Opcache and a Nagios check for PHP Opcache.

[[File:Opcache management status.png|800px]]

==See also==
* [http://pecl.php.net/package/ZendOpcache PECL ZendOPcache]
* [http://windows.php.net/downloads/pecl/releases/opcache/ Windows builds for PHP 5.3-5.4]

Forum discussions:
* [https://moodle.org/mod/forum/discuss.php?d=244133 OPcache: Memory Usage = 100% (is this good or bad?)]
* [https://moodle.org/mod/forum/discuss.php?d=245885 OPCode cache]

[[Category:Environment]]
[[Category:Installation]]
[[Category:Performance]]

[[es:OPcache]]

Question behaviours

2014-10-04T04:32:11Z

Battya: Added clarification to "Adaptive" question behavior.

Cron with MAC OS X

2014-03-21T07:03:19Z

Battya:

{{Cron}}
'''NOTE: This describes setting up Moodle's cron using OSX's launchd system. However, since OSX is a variant of Unix, cron is also an option. It should be noted, however, that OSX cron is actually managed by launchd.'''

==launchd==

In Mac OS X 10.5+ you will find the system daemon ''launchd'' for this service. This daemon offers a standardized interface to any user and all programs started automatically by the system. Please look at http://developer.apple.com/macosx/launchd.html for more informations about the configurations and all parameters.

The service should get the web page http://path.to.your/moodle/admin/cron.php every few minutes. The configuration will be done by the file named ''moodle4mac.cron.plist'' which must be placed in the system folder ''/Library/LaunchDaemons/'' ... surely you can use any other file name but it should say something about the function of the service. The extension must be ''.plist''. After any reboot of your Mac server the cron service will start automaticly because the file is placed in the correct system folder.

'''NOTE:''' Check the [[Cron settings]] to make sure running the web version of Moodle's cron is permitted.

===Use the graphical way===
You can use Lingon (no longer supported, unfortunately) to add a new daemon plist or to edit one. It produces the same text as you can write in your text editor. http://sourceforge.net/projects/lingon/files/

[[Image:macosx-lingon.png|thumb|center|Lingon screenshot]]

===Use a text editor===
Please use a text editor to write the needed file. You can open the Terminal and use the system editors vi or pico. But you can also write the text file with any GUI text editor ... I mostly use TextWrangler ... but do NOT take an editor for formatted texts like Microsoft Word or OpenOffice Writer. You must get pure text!

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>KeepAlive</key><false/>
<key>Label</key><string>moodle4mac.cron</string>
<key>ProgramArguments</key>
<array>
<string>curl</string>
<string>-s</string>
<string>http://your-server-address/moodle19/admin/cron.php</string>
</array>
<key>RunAtLoad</key><true />
<key>StartInterval</key><integer>300</integer>
<key>StandardErrorPath</key><string>/dev/null</string>
<key>StandardOutPath</key><string>/dev/null</string>
</dict>
</plist>

The label string must be the same as the file name is but without the extension ''.plist''. Save the text file ''/Library/LaunchDaemons/moodle4mac.cron.plist''. The owner of the file must be set to the system user ''root'' with the following:

sudo chown root /Library/LaunchDaemons/moodle4mac.cron.plist

If you use a site with SSL (ie: it has an http'''s''':// protocol) you either need to have your SSL certificates listed for use by the CURL utility ([http://curl.haxx.se/docs/sslcerts.html see these docs] for more details) OR you must use the '-k' switch in addition to the '-s' switch used above; your arguments line would then read: `<string>-s -k</string>`.

That's all, really!

===How to start and stop the cron service===
You can start the new cron service in the Terminal.

sudo launchctl load /Library/LaunchDaemons/moodle4mac.cron.plist

The following command would stop the service. If you want to activate changes in the cron service you need to ''unload'' and then to ''load'' the daemon again.

sudo launchctl unload /Library/LaunchDaemons/moodle4mac.cron.plist

===Only one service for two servers?===
For my server I needed to have a cron service for to instances ''moodle19'' and ''moodle20'' ... no problem ... with the typo ''moodle[19-20]'' I will get a cron service for both.

<nowiki>curl -s http://your-server-address/moodle[19-20]/admin/cron.php</nowiki>

To see if the cron service works correctly you should look at the ''access.log'' of your web server. The cron.php should be accessed every 5 minutes ... on my server for both Moodle instances ''moodle19'' and ''moodle20'' ... oh yes, it works!!

192.168.0.220 - - [30/Jul/2009:22:10:56 +0200] "GET /moodle19/admin/cron.php HTTP/1.1" 200 1136
192.168.0.220 - - [30/Jul/2009:22:10:57 +0200] "GET /moodle20/admin/cron.php HTTP/1.1" 200 1403
192.168.0.220 - - [30/Jul/2009:22:11:18 +0200] "OPTIONS * HTTP/1.0" 200 -
192.168.0.220 - - [30/Jul/2009:22:15:56 +0200] "GET /moodle19/admin/cron.php HTTP/1.1" 200 735
192.168.0.220 - - [30/Jul/2009:22:15:57 +0200] "GET /moodle20/admin/cron.php HTTP/1.1" 200 964
192.168.0.220 - - [30/Jul/2009:22:20:56 +0200] "GET /moodle19/admin/cron.php HTTP/1.1" 200 1136
192.168.0.220 - - [30/Jul/2009:22:20:57 +0200] "GET /moodle20/admin/cron.php HTTP/1.1" 200 1365

[[es:Cron con MAC OS X]]

Cron with MAC OS X

2014-03-21T06:22:08Z

Battya:

{{Cron}}
'''NOTE: This describes setting up Moodle's cron using OSX's launchd system. However, since OSX is a variant of Unix, we recommend simply using crontab, as it works just as well and is much simpler'''

==launchd==

In Mac OS X 10.5+ you will find the system daemon ''launchd'' for this service. This daemon offers a standardized interface to any user and all programs started automatically by the system. Please look at http://developer.apple.com/macosx/launchd.html for more informations about the configurations and all parameters.

The service should get the web page http://path.to.your/moodle/admin/cron.php every few minutes. The configuration will be done by the file named ''moodle4mac.cron.plist'' which must be placed in the system folder ''/Library/LaunchDaemons/'' ... surely you can use any other file name but it should say something about the function of the service. The extension must be ''.plist''. After any reboot of your Mac server the cron service will start automaticly because the file is placed in the correct system folder.

'''NOTE:''' Check the [[Cron settings]] to make sure running the web version of Moodle's cron is permitted.

===Use the graphical way===
You can use Lingon (no longer supported, unfortunately) to add a new daemon plist or to edit one. It produces the same text as you can write in your text editor. http://sourceforge.net/projects/lingon/files/

[[Image:macosx-lingon.png|thumb|center|Lingon screenshot]]

===Use a text editor===
Please use a text editor to write the needed file. You can open the Terminal and use the system editors vi or pico. But you can also write the text file with any GUI text editor ... I mostly use TextWrangler ... but do NOT take an editor for formatted texts like Microsoft Word or OpenOffice Writer. You must get pure text!

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>KeepAlive</key><false/>
<key>Label</key><string>moodle4mac.cron</string>
<key>ProgramArguments</key>
<array>
<string>curl</string>
<string>-s</string>
<string>http://your-server-address/moodle19/admin/cron.php</string>
</array>
<key>RunAtLoad</key><true />
<key>StartInterval</key><integer>300</integer>
<key>StandardErrorPath</key><string>/dev/null</string>
<key>StandardOutPath</key><string>/dev/null</string>
</dict>
</plist>

The label string must be the same as the file name is but without the extension ''.plist''. Save the text file ''/Library/LaunchDaemons/moodle4mac.cron.plist''. The owner of the file must be set to the system user ''root''. If you use a site with SSL (ie: it has an http'''s''':// protocol) you either need to have your SSL certificates listed for use by the CURL utility ([http://curl.haxx.se/docs/sslcerts.html see these docs] for more details) OR you must use the '-k' switch in addition to the '-s' switch used above; your arguments line would then read: `<string>-s -k</string>`.

That's all, really!

===How to start and stop the cron service===
You can start the new cron service in the Terminal.

sudo launchctl load /Library/LaunchDaemons/moodle4mac.cron.plist

The following command would stop the service. If you want to activate changes in the cron service you need to ''unload'' and then to ''load'' the daemon again.

sudo launchctl unload /Library/LaunchDaemons/moodle4mac.cron.plist

===Only one service for two servers?===
For my server I needed to have a cron service for to instances ''moodle19'' and ''moodle20'' ... no problem ... with the typo ''moodle[19-20]'' I will get a cron service for both.

<nowiki>curl -s http://your-server-address/moodle[19-20]/admin/cron.php</nowiki>

To see if the cron service works correctly you should look at the ''access.log'' of your web server. The cron.php should be accessed every 5 minutes ... on my server for both Moodle instances ''moodle19'' and ''moodle20'' ... oh yes, it works!!

192.168.0.220 - - [30/Jul/2009:22:10:56 +0200] "GET /moodle19/admin/cron.php HTTP/1.1" 200 1136
192.168.0.220 - - [30/Jul/2009:22:10:57 +0200] "GET /moodle20/admin/cron.php HTTP/1.1" 200 1403
192.168.0.220 - - [30/Jul/2009:22:11:18 +0200] "OPTIONS * HTTP/1.0" 200 -
192.168.0.220 - - [30/Jul/2009:22:15:56 +0200] "GET /moodle19/admin/cron.php HTTP/1.1" 200 735
192.168.0.220 - - [30/Jul/2009:22:15:57 +0200] "GET /moodle20/admin/cron.php HTTP/1.1" 200 964
192.168.0.220 - - [30/Jul/2009:22:20:56 +0200] "GET /moodle19/admin/cron.php HTTP/1.1" 200 1136
192.168.0.220 - - [30/Jul/2009:22:20:57 +0200] "GET /moodle20/admin/cron.php HTTP/1.1" 200 1365

[[es:Cron con MAC OS X]]

Git for Administrators

2014-03-13T02:33:20Z

Battya:

{{Installing Moodle}}
This page describes how to maintain a copy of Moodle on your production server which can easily be upgraded using Git. If you have customisations of Moodle core code, you are advised to follow the instructions in the [[Development:Quick Git start guide for Moodle development|Quick Git start guide for Moodle development]].

To get the most of of Git it is worth making the effort to understand its basic concepts - see the See also section below. It can be a bit of a learning curve, especially if you are used to CVS or Subversion.

== Getting hold of Git (Windows, OSX, Linux and others) ==

Support for Git was, up until recently, mostly confined to Linux but builds are now available for most popular operating systems:

* List of downloads from Git site - http://git-scm.com/download

Once you have downloaded and installed your OS relevant git installation, the git commands in this document should work with your operating system.

== Obtaining the code from Git ==

The command line version of Git is discussed here. Graphical clients are little more than wrappers around the command line version, so you should be able to deduce the correct parameters quite easily.

You can find the official Moodle git repository at git://git.moodle.org/moodle.git (with an official clone at git://github.com/moodle/moodle.git). To initialize your local checkout, use
<pre>
$ cd /path/to/your/webroot
$ git clone git://git.moodle.org/moodle.git (1)
$ cd moodle
$ git branch -a (2)
$ git branch --track MOODLE_26_STABLE origin/MOODLE_26_STABLE (3)
$ git checkout MOODLE_26_STABLE (4)
</pre>
* The command (1) initializes the new local repository as a clone of the 'upstream' (i.e. the remote server based) moodle.git repository. The upstream repository is called 'origin' by default. It creates a new directory named ''moodle'', where it downloads all the files. This operation can take a while as it is actually getting the entire history of all Moodle versions
* The command (2) lists all available branches.
* Use the command (3) to create a new local branch called MOODLE_26_STABLE and set it to track the remote branch MOODLE_26_STABLE from the upstream repository.
* The command (4) actually switches to the newly created local branch.

Note that Git has a huge number of options for each command and it's actually possible to do the above process with a single command (left as an exercise!!).

==Git from behind a firewall==

Git uses a read-only protocol that may be blocked by your firewall (port 9418). If this is a problem, you can use Github's http version <nowiki>https://github.com/moodle/moodle.git</nowiki>. It's a bit slower, so use the Git protocol if you can.

== Updating your installation ==

The Moodle development team performs integration and testing of fixed bugs every Monday and Tuesday. On Wednesday you can install all patches by updating your code. Check the [http://git.moodle.org/gw?p=moodle.git;a=summary shortlog] to see if the official repository has been already updated or not.

To update your code to the latest version (on the MOODLE_26_STABLE branch) '''all''' you have to do is:
<pre>
$ cd /path/to/your/moodle/
$ git pull
</pre>
If this is a production site you should still consider the [[Upgrade]] instructions (e.g. take backups).

== Installing a contributed extension from its Git repository ==

This is one way to handle adding plugins from other Git repositories into your Moodle repository. Another way is to use Git Submodules. However, at the time of writing, this is one of Git's rougher features and should be regarded as an advanced option.

For example, let us say we want to install the [[Certificate module]] from its Git repository into our Moodle 2.6.
<pre>
$ cd /path/to/your/moodle/
$ cd mod (1)
$ git clone https://github.com/markn86/moodle-mod_certificate.git certificate (2)
$ cd certificate
$ git checkout -b MOODLE_26_STABLE origin/MOODLE_26_STABLE (3)
$ git branch -d master (4)
</pre>
The command (1) changes the current directory into the ''mod'' folder of your local Moodle clone. The command (2) creates a new subdirectory ''certificate'' and makes a local clone of vanilla Certificate repository. The command (3) creates a new local branch that will track the remote branch with a Certificate version for Moodle 2.6. The command (4) deletes the ''master'' that was created automatically by git-clone in (2) as we do not want it in this production checkout.

Note: you should check first the compatibility of a module with your Moodle branch by asking directly to the Maintainer before cloning the repo or - if you want to guess it - by issueing the command below before running the command (3), in order to verify what is available among the branches:
<pre>
$ git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/MOODLE_20_STABLE
remotes/origin/MOODLE_21_STABLE
remotes/origin/MOODLE_22_STABLE
remotes/origin/MOODLE_23_STABLE
remotes/origin/MOODLE_24_STABLE
remotes/origin/MOODLE_25_STABLE
remotes/origin/MOODLE_26_STABLE
remotes/origin/master
</pre>
This will avoid an error message when you issue the command (3) against a nonexistent branch, e.g.:
<pre>
§ git checkout -b MOODLE_27_STABLE origin/MOODLE_27_STABLE
fatal: git checkout: updating paths is incompatible with switching branches.
Did you intend to checkout 'origin/MOODLE_27_STABLE' which can not be resolved as commit?
</pre>

Now it is wise to put the new directory mod/certificate/ to the list of ignored files of the main Moodle clone, otherwise a status of the main clone will keep reminding you that the new code has not been checked in.
<pre>
$ cd /path/to/your/moodle/
$ echo /mod/certificate/ >> .git/info/exclude
</pre>
To update your Moodle installation now, you must visit both Git repositories and pull changes from upstream.
<pre>
$ cd /path/to/your/moodle/
$ git pull
$ cd mod/certificate
$ git pull
</pre>
Writing a shell script with these lines in the root of Moodle installation is a very good idea. Otherwise it is easy to forget what Git repositories are there within the main Moodle repository.

== See also ==

; Moodle Docs
* [[Git FAQ]]
* [[Windows installation using Git]]
* [[Git for Mac]]
* [[:dev:Moodle versions]]
* For some screenshots see [[User:Frank_Ralf/Git]] (still work in progress)
* For fixing a Tracker Issue (MDL) / Forking Moodle / CONTRIButing code ... [[User:Sam_Hemelryk/My_Moodle_Git_workflow]]
* [[Moodle_Production_Server_with_GIT|Case study Git + Moodle from Technical University Berlin]]

; Moodle forum discussions
* [https://moodle.org/mod/forum/discuss.php?d=255175 Github and Moodle deployment for production]
* [https://moodle.org/mod/forum/discuss.php?d=213695 Got GIT installed on my site- here's how!]
* [http://moodle.org/mod/forum/discuss.php?d=168094 GIT help needed]
* [http://moodle.org/mod/forum/discuss.php?d=165236 Best way to manage CONTRIB code with GIT]
* [http://moodle.org/mod/forum/discuss.php?d=167063 Handy Git tip for tracking 3rd-party modules and plugins]
* [http://moodle.org/mod/forum/discuss.php?d=167730 Moodle Git repositories]
* [http://moodle.org/mod/forum/discuss.php?d=183693 Git and CVS]
* [http://moodle.org/mod/forum/discuss.php?d=208904 GIT for dummies]
* [http://moodle.org/mod/forum/discuss.php?d=211930 Git and upgrading misunderstanding]
* [https://moodle.org/mod/forum/discuss.php?d=231046 Clear git guide for Admins (not developers)]

; External resources
* [http://thamblings.blogspot.com.au/2013/07/upgrading-moodle-from-git.html Deploying Moodle from git - Blog post from a production experience]
* [http://www.kernel.org/pub/software/scm/git/docs/everyday.html Everyday GIT With 20 Commands Or So]
* [http://gitref.org/ Git Reference]
* [http://progit.org/book/ Pro Git book]
* [http://eigenjoy.com/2008/05/15/git-from-the-bottom-up/ Git from the bottom up]

[[ja:管理者用Git]]
[[fr:Git_pour_administrateurs]]
[[es:Git para Administradores]]