MoodleDocs - Wkład użytkownika [pl]

Autolinking

2014-02-15T09:14:14Z

Scaroodle: Fixed a typo.

{{Filters}}
[[Image:glossary autolinking.png|right]]
Autolinking is a feature of Moodle by which words or phrases used within a Moodle site are automatically linked (by highlighting in grey by default) to a glossary and database entries, and activity and resources within the course with the same name.

Autolinking can be managed at different levels in Moodle:

*Site wide: it can be switched on/off by going to ''Settings > Site Administration > Plugins > Filters > Manage Filters.''

*Moodle courses: it can be managed within individual courses from ''Settings > Course Administration > Filters''

*Resources & Activities within a Moodle course: it can also be managed from within an activity or resource from ''Settings > [Activity name] Administration > Filters''. This is useful for turning off auto-linking to glossaries for example in a quiz, when you don't want the answer to be revealed to the student via an auto-linked glossary term being present in a question.

*Specific text : Within activities and resources certain text can have the auto-linking disabled by highlighting the text in question and clicking on the ''Prevent automatic linking'' button (chain with a red cross through it). Alternatively, if you are viewing the text in HTML markup mode, links can be prevented by adding <nowiki><nolink> ... </nolink></nowiki> tags around the relevant content.
Another way to force autolinking on/off in HTML markup mode is to use:
* <nowiki><span class="link">text</span></nowiki>
* <nowiki><span class="nolink">text</span></nowiki>

For more information on autolinking, see [[Filters|Filters]].

==See also==

*[[Managing filters]]

Theme settings

2014-01-03T20:42:18Z

Scaroodle: Added a note about enabledevicedetection. See https://moodle.org/mod/forum/discuss.php?d=246447.

{{Themes}}
== Theme settings ==
An administrator can change theme settings in ''Settings > Site administration > Appearance > Themes > Theme settings''.

[[File:Themesettings.png]]

===Theme list===
This lists the themes available for course and user themes. Leave this blank to allow any valid theme to be used. If you want to shorten the theme menu, you may specify a comma-separated list of names, though don't use spaces (e.g. standard,orangewhite).

You can preview the available themes in ''Administration > Site Administration > Appearance > Themes > Themes selector.''

===Theme designer mode===
Turn this on if you are designing and testing themes as it will stop the themes being cached and enable you to see theme changes quickly. (You can also do this with the Clear theme cache button on the theme selector page.)

===Allow user themes===
If the option ''allowuserthemes'' is enabled, each user may select their preferred theme on the edit profile page. All Moodle pages will be displayed in the user's theme, apart from courses where a course theme has been set.

'''NOTE:''' the user's theme will not be available in mobile and tablet devices unless the option ''enabledevicedetection'' is unchecked.

===Allow course themes===
If you enable this, then teachers will be able to set their own course themes. Course themes override all other theme choices (site, user, or session themes).

*If the option ''allowcoursethemes'' is enabled, each editing teacher may select their course theme via the Force theme option on the [[course/edit|Course settings]] page. The course will always be displayed in the theme specified in the course setting, with user and the site themes being overwritten.

'''NOTE:''' the course theme will not be available in mobile and tablet devices unless the option ''enabledevicedetection'' is unchecked.

===Allow category themes===
When enabled, themes can be set at the category level. This will affect all child categories and courses unless they have specifically set their own theme. WARNING: Enabling category themes may affect performance, as it will result in a few extra DB queries on each page, so only turn this on if you need it!

'''NOTE:''' the category theme will not be available in mobile and tablet devices unless the option ''enabledevicedetection'' is unchecked.

===Allow theme changes in the URL===
*If this is checked then the theme may be changed by adding <code>?theme=theme_name</code> (or <code>&theme=theme_name</code> if there are other URL parameters) to the URL in the browser. Theme names should be in lower case with spaces replaced by underscores, for example the theme "Formal white" should be entered as <code>?theme=formal_white</code>

===Allow users to hide blocks===
Allows users to display and hide blocks

===Allow blocks to use the docks===
*If the theme allows it, then checking this will allow the user to move blocks to the side dock.

===Custom menu items===
The custommenuitems setting allows you to create a drop down menu that can be displayed by themes that support it. Currently all themes that are provided with Moodle 2.0 support this custom menu.

You are able to create the custom menu by entering custom menu items one per line into the setting. Each item is preceded by a number of hyphens (-), the number of hyphens determines the depth of the item. So items that are '''NOT''' preceded by a hyphen appear on the top level of the menu (always visible), items with a single hyphen appear on a drop down menu below the previous top level item, and items with two hyphens appear on a drop down menu below the previous first level item and so on.

The content of each item is constructed of up to three bits, each separated by a '''|''' (Shift + \) character. The bits are '''label''' | '''url''' | '''tooltip'''.
; label : This is the text that will be shown within the menu item. You must specify a label for every item on the menu.
; url : This is the URL that the user will be taken to it they click the menu item. This is optional, if not provided then the item will not link anywhere.
; tooltip : If you provide a URL you can also choose to provide a tooltip for the link that is created with the URL. This is optional and if not set the label is used as the tooltip for the menu item.

The following is an example of how you would create a custom menu:

<pre>
Moodle community|http://moodle.org
-Moodle free support|http://moodle.org/support
-Moodle development|http://moodle.org/development
--Moodle Tracker|http://tracker.moodle.org
--Moodle Docs|https://docs.moodle.org
-Moodle News|http://moodle.org/news
Moodle company
-Moodle commercial hosting|http://moodle.com/hosting
-Moodle commercial support|http://moodle.com/support
</pre>

Note: The custom menu does not escape characters within the label, if you want to use a special HTML character such as an ampersand you must escape it yourself within the label. e.g. use & instead of &.

For more information on this setting please see the ''Using Moodle'' forum discussion [http://moodle.org/mod/forum/discuss.php?d=149803 Moodle 2.0: Custom menu in core]

==== Multilanguage support ====

You can add a language code (or a comma separated list of codes) as the 4th item of the line. The line will be then printed if and only if the user has currently selected the listed language. For example:

<pre><nowiki>
English only|http://moodle.com|English only item|en
German only|http://moodle.de|Deutsch|de,de_du,de_kids
</nowiki></pre>

==== Adding other attributes to the HTML ====
Other attributes, such as '''target''' can be added with escaped quotes:
<pre><nowiki>
Moodle Homepage|http://moodle.org\" target=\"_blank
</nowiki></pre>
The first escaped quote closes the href attribute, allowing other attributes to be added. All quotes for the extra attributes must be escaped as well. Do not add the closing quotation mark on the final attribute, it is added automatically by Moodle.

===Enable device detection===
Will detect mobile and tablets that identify themselves via the web browser at the time of login to Moodle. These work with the theme selector. When the theme selector has identified a default, mobile and tablet themes, this feature will use that theme.

===Device detection regular expressions===
This will allow you to customize the theme selector options. For example, you can add a custom theme for IE6 and another for Windows CE by entering the identifying expressions the browser sends and the "Return value" you want to display as the theme selectors "Device type".

==Special themes==

=== Session themes ===
Moodle offers an additional way to set a theme - the '''session theme'''. This is set with the URL and lasts until you log out. When you next login, the site/course/user themes are active again. This option is great for theme testing and works perfectly when you want to enable different themes for different situations.

For example you can offer a special link for PDA users and integrate the session theme ''orangewhitepda'' in that link. Nobody needs to change any settings, you just click on that link. The session theme is called by the URL parameter <code>&theme=orangewhitepda</code>. The whole URL without the session theme could look like <code><nowiki>http://mymoodlesite.org/course/view.php?id=18</nowiki></code> and with the parameter for the PDA theme like <code><nowiki>"http://mymoodlesite.org/course/view.php?id=18&theme=orangewhitepda"</nowiki></code>.

In a standard Moodle installation, session themes are not active. To activate them the administrator must add the parameter <code>$CFG->allowthemechangeonurl = true;</code> to the Moodle ''config.php'' file in the Moodle base directory.

=== Page theme ===
A page theme is for special page-only themes set by code, use <code>$PAGE->force_theme()</code>.

== Theme hierarchy ==
Here is the usual order that themes are considered by the Moodle interface.

{| style="border:1px dashed #ddd"
|- style="vertical-align:top;text-align:left"
!Theme type
! style="background:#eee"|Overwrites
!Display
! style="background:#eee"|Setting type
|- style="vertical-align:top"
|Site
|style="background:#eee"| -
|all pages*
|style="background:#eee"|saved in theme profile
|- style="vertical-align:top"
|User
|style="background:#eee"|Site theme
|all pages*
|style="background:#eee"|saved in user profile
|- style="vertical-align:top"
|Course
|style="background:#eee"|Site, user and session themes
|one course
|style="background:#eee"|saved in course profile
|- style="vertical-align:top"
|Session
|style="background:#eee"|Site and user themes
|all pages*
|style="background:#eee"|temporary until logout
|}
(* except courses with the course theme set)

=== Change default hierarchy===
The priority of themes can be set via the /moodle/config.php file. The order defines which theme wins when there are several set at different levels. You can set a variable called $CFG->themeorder (see config-dist.php for more details). By default it is set to:

<code><nowiki>$CFG->themeorder = array('course', 'category', 'session', 'user', 'site');</nowiki></code>

==Particular theme settings==

Logo, tagline, link colour, column width, custom CSS and other settings for a particular theme may be set by an administrator in ''Administration > Site administration > Appearance > Themes > Theme name''.

[[es:Configuración de temas]]
[[fr:Réglages des thèmes]]
[[ja:テーマ設定]]
[[de:Design-Einstellungen]]

TeX notation filter

2013-12-10T22:26:55Z

Scaroodle: Added an explicit reference to the three PHP functions required by the filter code, included the debugging tool.

{{Filters}}
The TeX Filter is a core Moodle filter intended to allow one to convert tex expressions into GIF images. The filter relies on three binaries to accomplish this for expressions contained between appropriate tokens. Where these binaries are not available, Moodle provides for a fallback through the use of Mimetex. Versions of MimeTex for Linux (glib2.3), Windows, Mac OS X and FreeBSD are included in the Moodle distribution. There are other technologies available for displaying Tex (see the section on [[Mathematics]] tools for a discussion.)

'''Note''': being based on binaries it requires the availability of three PHP program execution functions: <code><nowiki>exec</nowiki></code>, <code><nowiki>shell_exec</nowiki></code> and <code><nowiki>system</nowiki></code>.

== Methods and Usage ==

To avoid confusion you should note that the TeX filter has two separate methods for converting the TeX notation to images. The preferred method is a collection of three binaries that you are responsible for installing (if they are not already present, though many webhosts make these available) and configuring on your server. The filter settings page relates entirely to this method. If this fails for any reason the filter will fall back to a single binary - MimeTeX. A number of different builds are included in the Moodle distribution for popular operating systems, though Mimetex and its bigger brother, MathTex are easy enough to compile and install if you have systems administration experience.

Before doing anything else, you need to go to ''Settings > Site administration > Plugins > Filters'' and activate the TeX Notation Filter. If you want to use the Algebra filter (another core filter) since the Algebra Filter is really only a "front end" to the Tex filter, you should also turn on the Algebra filter. For more information on the Algebra Filter see the [[Algebra filter]].

Once the filter is turned on and properly configured you can make use of it by
including a TeX expression delimited by double-dollar signs. Example:

$$ \sqrt{x + y} $$

If this does not display properly, see the information on debugging.

== MimeTeX ==

Moodle may use a pre-built MimeTeX binary (located in the filters/tex directory) as a fallback if it can't properly access dvips, convert and latex binaries. There are a number of different versions for different operating systems. The TeX filter picks the appropriate binary for the detected host operating system (you will need to hack the script if your operating system is not included). Note that your web server needs to be set up with appropriate permissions for running binaries in that location.

The [http://www.forkosh.com/mimetexmanual.html MimeTeX manual] is available but is arguably intended for persons with systems administration experience and does not specifically address the Moodle environment.

You should only user MimeTeX if installing the full LaTeX system fails or the binaries are not available on your system. The results are not nearly as good.

== Site administration settings ==

Location: TeX Notation settings link in ''Settings > Site administration > Plugins > Filters > Manage filters''

The TeX filter settings page are primarily intended to adjust the operation of the LaTeX renderer. The defaults for the three path settings are selected according to the detection of the operating system on which Moodle is running. These are simply suggested common values - Moodle does not check that the binaries actually exist at these locations. More recent versions of Moodle show a green tick or a red cross next to the path setting - this shows that the binary exists at that location (only). The settings have no effect on the operation of the MimeTex binary (used if any of these binaries are not found).

==== Installing the binaries ====

This depends on your platform, but for a typical install you are going to need a LaTeX implementation. On modern Linux implementations you should look for the 'texlive' package (e.g. ''apt-get install texlive'') although a Windows version is available (see [http://www.tug.org/texlive/doc/texlive-en/texlive-en.html Tex Live]). It is highly unlikely that you will have all these binaries as part of a standard install. If you cannot find texlive you may have to install LaTeX, Ghostscript and ImageMagick separately. While not endorsed by Moodle.org, a simple installation binary for Windows is [http://miktex.org/| MikTeX].

The filter settings page will try to guess the most likely location for the binary files depending on the detected platform. If correct, green ticks will appear against each setting. If red crosses appear you will need to check and modify the settings as required. A simple check is made to establish if the binaries exist at the given paths. A tick or a cross is displayed alongside each as a result. Note that this does not check that the application actually works, just that it is there.

Some systems supply the fonts as separate packages. If you are having problems make sure you have all the fonts you need installed. You may need to track down an 'extra' fonts package to get the required maths fonts.

==== LaTeX preamble ====

Enables the LaTeX preamble to be specified. The default should work for most users, but you may need to change it to support non-latin character sets etc. Please see the LaTeX documentation for further details.

==== Transparent colour ====

This should be set to your normal text background colour. The default setting is #FFFFFF (i.e., white).

==== Density ====

This setting effects the size of the resulting image. The default setting is 120 pixels, and it produces an image of reasonable quality, but for some complicated equations, this still may not be enough. It may be that anything less is not going to produce an image of sufficient quality but the image size can be controlled by the TeX encoding when the page is rendered.

==== Path of ''latex'' binary ====

Path to standard latex binary.

On Unix based systems it is normally "/usr/bin/latex". On a MacOS X, the path is "/usr/texbin/".

In Windows, using MiKTeX, it is usually something like C:\texmf\miktex\bin\latex.exe

==== Path of ''dvips'' binary ====

Path to standard dvips binary - generally distributed as part of a LaTeX system.

On Unix based systems it is normally "/usr/bin/dvips". On a MacOS X, the path is "/usr/texbin/".

On Windows using MikTeX is is usually something like C:\texmf\miktex\bin\dvips.exe

==== Path of ''convert'' binary ====

Path to standard convert binary. This is distributed as part of the Ghostscript system, or ImageMagick in Linux.

On Unix based systems it is normally "/usr/bin/convert". On a MacOS X, the path is "/usr/local/bin/".

On a Windows based PC the path is something like C:\Program Files\ImageMagick\convert.exe (for ImageMagick, but something else for GhostScript.)

== Debugging TeX filter ==

The TeX filter has a debugging script (which will be much more helpful if you turn moodle debugging on) included that should help if you are having problems. The URL will be as follows...

<nowiki>http://your.moodle.path/filter/tex/texdebug.php</nowiki>

You can either enter this path explicitly or with appropriate role permissions the TeX images (or more likely incorrectly rendered text, if you need debugging) will link to this. On more recent versions of Moodle you are ''required'' to be logged in as an Administrator to access this facility.

== See also ==

* [http://moodle.org/mod/glossary/view.php?id=2739&mode=letter&hook=M&sortkey=CREATION&sortorder=asc TeX Filter Glossary] - a [[Glossary|glossary]] you can add to your course which details usage of the supported [[TeX notation]].
* [http://www.latex-project.org/ LaTeX] - the LaTeX document preparation system.
* [http://www.ghostscript.com/ ghostscript] - required to render the image
* [http://www.forkosh.com/mimetexmanual.html MimeTeX Manual] - Default TeX notation manual
* [http://www.miktex.org/ MikTeX] - LaTeX for Windows systems
* [http://www.imagemagick.org/script/index.php ImageMagick] - required to render images for Windows
* [[Using TeX Notation]]
* [[Advanced Maths Tools]] for Moodle 2.x - SEE - The Next Generation of TeX Tools

[[Category:Site administration]]
[[Category:Mathematics]]

[[de:TeX-Notation]]

Caching

2013-08-11T07:36:35Z

Scaroodle: /* See also */ More references about the reasons for having a shared MUC file store

{{Performance}}

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

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

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

==General approach to performance testing==

Here is the general strategy you should be taking:

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

==How to use the caching settings==

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

=== Types of cache ===

Moodle uses three types of cache to store cached data:
* Request cache - The request cache is available for the duration of every page request. It is not shared between users and is used and cleared on every Moodle request.
* Session cache - The session cache is available through a users session in Moodle. It is not shared between users, but persists for a single user throughout their session (i.e. from when they logon til when they log off)
* Application cache - The application cache is a shared cache which is available for every request. It can be shared between users and the cached data can be kept indefinitely if required.

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

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

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

===Installed cache stores===

This section of the administrator screen displays cache plugins which are installed on the system. It lists what the capabilities of each plugin, what type of cache they provide and provides allows a cache store to be added to the system.

===Configured store instances===

This section of the administrator screen displays cache stores which have been added to the system. It gives the ability to change the cache configuration and purge the cached data.

===Cache lock instances===

Moodle supports different mechanisms for 'locking' access to the various cache stores. At present there is only one option and it is not used, so it can safely be ignored.

===Known cache definitions===

Known cache definitions displays the caches which are in use by Moodle. Each item is an area of Moodle which is using caching. It gives the administrator the ability to configure an individual area of Moodle to use a different cache backend. For example, an administrator of a Moodle cluster may choose to make language string definitions be cached on a dedicated memcached server by using the memcached cache backend. See the section below for more information about configuring these.

==Cache definition configuration==

Each different cache can be configured independently, allowing admins to "tune" their setup for particular systems.

By default these caches are all set to use files, which is usually fine on a small one-server system.

On a cluster, however, these defaults can cause problems because shared filesystems are slow, so in these cases we recommend you use a faster shared caching backend like memcached instead. Note that most of these caches operating under the assumption that they are shared.

In some cases you can choose to use a non-shared cache like the local filesystem however in these instances you be careful to purge caches MANUALLY as part of system administration.

The following reference is intended to help you understand how each caching definition works so you can tune appropriately:

(Note to doc editors, we need contributions below:)

===Language string cache===

* What is cached:
* When the cache is updated:
* How often it is hit:
* When should the cache be purged completely:

===Database meta information===
===Event invalidation===
===Question definitions===
===HTML Purifier - cleaned content===
===Config settings===
===Course group information===
===Calendar subscriptions===
===YUI Module definitions===
===Plugin types===
===Plugin list Application===
===Plugin info - base===
===Plugin info - activity modules===
===Plugin info - blocks===
===Plugin info - filters===
===Plugin info - repositories===
===Plugin info - portfolios===
===Course categories tree===
===Course categories lists for particular user===
===Course categories records===
===List of course contacts===
===Repositories instances data===

==Stores used when no mapping is present==

This section displays the default cache stores which should be used by Moodle for each type of Moodle cache. If a mapping for a cache definition does not exist then this default store will be used instead.

==Other performance testing==

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

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

==Performance advise for Moodle 2.5 with load-balanced web servers==

Performance advice: if you are running Moodle 2.4 onwards with load-balanced web servers, don't use the default caching option that stores the data in moodledata on a shared network drive. Use memcache instead. See Tim Hunt's article on http://tjhunt.blogspot.de/2013/05/performance-testing-moodle.html.

==See also==

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

Developer documentation:
* [[:dev:The Moodle Universal Cache (MUC)]]
* [[:dev:Cache API]]
* [[:dev:Cache API - Quick reference]]

[[de:Caching]]

Caching

2013-08-11T07:32:45Z

Scaroodle: /* See also */ Added a reference about $CFG->cachedir not being local but shared (MDL-38059)

{{Performance}}

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

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

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

==General approach to performance testing==

Here is the general strategy you should be taking:

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

==How to use the caching settings==

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

=== Types of cache ===

Moodle uses three types of cache to store cached data:
* Request cache - The request cache is available for the duration of every page request. It is not shared between users and is used and cleared on every Moodle request.
* Session cache - The session cache is available through a users session in Moodle. It is not shared between users, but persists for a single user throughout their session (i.e. from when they logon til when they log off)
* Application cache - The application cache is a shared cache which is available for every request. It can be shared between users and the cached data can be kept indefinitely if required.

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

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

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

===Installed cache stores===

This section of the administrator screen displays cache plugins which are installed on the system. It lists what the capabilities of each plugin, what type of cache they provide and provides allows a cache store to be added to the system.

===Configured store instances===

This section of the administrator screen displays cache stores which have been added to the system. It gives the ability to change the cache configuration and purge the cached data.

===Cache lock instances===

Moodle supports different mechanisms for 'locking' access to the various cache stores. At present there is only one option and it is not used, so it can safely be ignored.

===Known cache definitions===

Known cache definitions displays the caches which are in use by Moodle. Each item is an area of Moodle which is using caching. It gives the administrator the ability to configure an individual area of Moodle to use a different cache backend. For example, an administrator of a Moodle cluster may choose to make language string definitions be cached on a dedicated memcached server by using the memcached cache backend. See the section below for more information about configuring these.

==Cache definition configuration==

Each different cache can be configured independently, allowing admins to "tune" their setup for particular systems.

By default these caches are all set to use files, which is usually fine on a small one-server system.

On a cluster, however, these defaults can cause problems because shared filesystems are slow, so in these cases we recommend you use a faster shared caching backend like memcached instead. Note that most of these caches operating under the assumption that they are shared.

In some cases you can choose to use a non-shared cache like the local filesystem however in these instances you be careful to purge caches MANUALLY as part of system administration.

The following reference is intended to help you understand how each caching definition works so you can tune appropriately:

(Note to doc editors, we need contributions below:)

===Language string cache===

* What is cached:
* When the cache is updated:
* How often it is hit:
* When should the cache be purged completely:

===Database meta information===
===Event invalidation===
===Question definitions===
===HTML Purifier - cleaned content===
===Config settings===
===Course group information===
===Calendar subscriptions===
===YUI Module definitions===
===Plugin types===
===Plugin list Application===
===Plugin info - base===
===Plugin info - activity modules===
===Plugin info - blocks===
===Plugin info - filters===
===Plugin info - repositories===
===Plugin info - portfolios===
===Course categories tree===
===Course categories lists for particular user===
===Course categories records===
===List of course contacts===
===Repositories instances data===

==Stores used when no mapping is present==

This section displays the default cache stores which should be used by Moodle for each type of Moodle cache. If a mapping for a cache definition does not exist then this default store will be used instead.

==Other performance testing==

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

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

==Performance advise for Moodle 2.5 with load-balanced web servers==

Performance advice: if you are running Moodle 2.4 onwards with load-balanced web servers, don't use the default caching option that stores the data in moodledata on a shared network drive. Use memcache instead. See Tim Hunt's article on http://tjhunt.blogspot.de/2013/05/performance-testing-moodle.html.

==See also==

Using Moodle forum discussions:
* [https://moodle.org/mod/forum/discuss.php?d=217195 MUC is here, now what?]
* [https://moodle.org/mod/forum/discuss.php?d=226123 Status of MUC?]
* [https://moodle.org/mod/forum/discuss.php?d=222250 Putting cachedir on local disks in cluster]

Developer documentation:
* [[:dev:The Moodle Universal Cache (MUC)]]
* [[:dev:Cache API]]
* [[:dev:Cache API - Quick reference]]

[[de:Caching]]

Git for Administrators

2013-06-21T20:14:19Z

Scaroodle: Typo and rewording

{{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>
$ git clone git://git.moodle.org/moodle.git (1)
$ cd moodle
$ git branch -a (2)
$ git branch --track MOODLE_25_STABLE origin/MOODLE_25_STABLE (3)
$ git checkout MOODLE_25_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_25_STABLE and set it to track the remote branch MOODLE_25_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_22_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 [[Book module]] from its Git repository into our Moodle 2.2.
<pre>
$ cd /path/to/your/moodle/
$ cd mod (1)
$ git clone git://github.com/skodak/moodle-mod_book.git book (2)
$ cd book
$ git checkout -b MOODLE_22_STABLE origin/MOODLE_22_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 ''book'' and makes a local clone of Petr Škoda's vanilla Book repository. The command (3) creates a new local branch that will track the remote branch with a Book version for Moodle 2.2. 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_15_STABLE
remotes/origin/MOODLE_17_STABLE
remotes/origin/MOODLE_18_STABLE
remotes/origin/MOODLE_19_STABLE
remotes/origin/MOODLE_20_STABLE
remotes/origin/MOODLE_21_STABLE
remotes/origin/MOODLE_22_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_25_STABLE origin/MOODLE_25_STABLE
fatal: git checkout: updating paths is incompatible with switching branches.
Did you intend to checkout 'origin/MOODLE_25_STABLE' which can not be resolved as commit?
</pre>
In this case you should ask the Mantainer, here Petr Škoda, if ''master'' is the correct branch for Moodle 2.3+ and he will reply that the [[Book module]] has been already integrated in Moodle starting from 2.3 so there's no need to install it usit ''git''. Please, as a general rule, before asking the Mantainer for something you should check the online documentation.

Now it is wise to put the new directory mod/book/ 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/book/ >> .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/book
$ 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]]
* [[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=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://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]]

Git for Administrators

2013-06-20T20:12:13Z

Scaroodle: Minor fixes as a potential response to https://moodle.org/mod/forum/discuss.php?d=231046

{{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>
$ git clone git://git.moodle.org/moodle.git (1)
$ cd moodle
$ git branch -a (2)
$ git branch --track MOODLE_25_STABLE origin/MOODLE_25_STABLE (3)
$ git checkout MOODLE_25_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_25_STABLE and set it to track the remote branch MOODLE_25_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_22_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 [[Book module]] from its Git repository into our Moodle 2.2.
<pre>
$ cd /path/to/your/moodle/
$ cd mod (1)
$ git clone git://github.com/skodak/moodle-mod_book.git book (2)
$ cd book
$ git checkout -b MOODLE_22_STABLE origin/MOODLE_22_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 ''book'' and makes a local clone of Petr Škoda's vanilla Book repository. The command (3) creates a new local branch that will track the remote branch with a Book version for Moodle 2.2. 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 the availability of a module for your Moodle branch by asking directly to the Maintainer before cloning the repo or 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_15_STABLE
remotes/origin/MOODLE_17_STABLE
remotes/origin/MOODLE_18_STABLE
remotes/origin/MOODLE_19_STABLE
remotes/origin/MOODLE_20_STABLE
remotes/origin/MOODLE_21_STABLE
remotes/origin/MOODLE_22_STABLE
remotes/origin/master
</pre>
This will avoid an error message when you issue the command (3) against a not existent branch:
<pre>
§ git checkout -b MOODLE_25_STABLE origin/MOODLE_25_STABLE
fatal: git checkout: updating paths is incompatible with switching branches.
Did you intend to checkout 'origin/MOODLE_25_STABLE' which can not be resolved as commit?
</pre>
In this case you should ask the Mantainer, here Petr Škoda, if ''master'' is the correct branch for Moodle 2.3+ and he will reply that the [[Book module]] has been already integrated in Moodle starting from 2.3 so there's no need to install it usit ''git''. Please, as a general rule, before asking the Mantainer for something you should check the online documentation.

Now it is wise to put the new directory mod/book/ 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/book/ >> .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/book
$ 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]]
* [[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=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]

; External resources
* [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]]