{{Accounts}}
An administrator can upload multiple cohorts from a CSV (comma separated values) formatted text file in ''Administration > Site administration > Users > Accounts > Cohorts > Upload cohorts''. Cohorts can be created in both the system (site-wide) context or in the [[Course_categories|course category context]]. {{New features}}

==Upload cohort process==
Here is an outline of the process:

# Create cohort file for uploading (CSV text file with a 'name' column and the name of each new cohort on a new line)
# Go to ''Administration > Site administration > Users > Accounts > Cohorts > Upload cohorts'
# Add file to upload
# Upload cohort preview - review settings and check for any errors. If errors are reported with the file, correct as needed.
# Upload cohorts - click "Upload cohorts"
# Upload cohorts results - shows how many cohorts were created
# Upload cohorts results - click "Continue"
# Returns to Upload users screen

===Settings===
====File====
The CSV formatted text file containing cohort data to be uploaded. See the [[cohort/upload#File_format_for_the_upload_cohorts_file|File format for the upload cohorts file]] section for more detailed information about the cohorts upload file.

====CSV delimiter====
The character used as a delimiter between fields in the cohort upload file. The delimiter separates the various fields on a single line. By default, a comma (',') is used as the delimiter; however, other options are available.
; <pre>,</pre> - uses the comma character as the field delimiter
; <pre>;</pre> - uses the semicolon character as the field delimiter
; <pre>:</pre> - uses the colon character as the field delimiter
; <pre>\t</pre> - uses \t (tab) as the field delimiter

====Encoding====
You can specify the character encoding of the upload cohorts file. The default character encoding is UTF-8.
====Default context====
You can specify the default context to use from a list of available contexts. The default context is the System context (i.e. site-wide). A list of course categories will be listed and one of those course categories can be selected as the default context if one is not provided in the upload cohorts file. If the <code>contextid</code> (or one of the available fields to lookup the <code>contextid</code>) is provided, then that value will be used; however, if a contextid is not provided for a particular cohort the default context will be used.

==File format for the upload cohorts file==
The upload cohorts CSV text file has fields separated by a comma (or other delimiter). The first line contains valid field names (preferrably lower case). The rest of the lines (records) contain information about each new cohort.

'':Tip:'' Avoid special characters in field information like quotes or other commas. Test a file with only one record before a large upload.
'':Tip:'' You can use a spreadsheet program to create the file with the required columns and fields. Then save the file as "CSV (comma delimited)". These files can then be opened with simple text editors for verification.

===Valid upload file for testing===
Here is an example of a simple valid upload cohorts file:
(Column headers on the first line of the file are only highlighted in bold in this example to distinguish it from the rest of the of the data/user details)

'''name,idnumber,description'''
Class of 2019,2019,Members of the Class of 2019
Class of 2020,2020,Members of the Class of 2020

===Fields that can be included===

*'''Required fields''':
:<code>name</code> - the name of the cohort to be created

*'''Optional fields''': To provide values other than the default include one or more of the following optional fields:
:<code>contextid</code> - used to specify the context id number of the cohorts you are uploading. For example, the context id number of a particular course category.
:<code>idnumber</code> - used to provide an id number for the cohorts you are uploading
:<code>description</code> - used to provide a description for the cohorts you are uploading
:<code>descriptionformat</code> - used to specify the text format of the description. By default, the descriptionformat is set to the recommended value of 1 (FORMAT_HTML); however, values of 0 (FORMAT_MOODLE) and 2 (FORMAT_PLAIN) are also available. These format values are defined in lib/weblib.php.
:<code>visible</code> - used to specify whether the cohorts you are uploading should be visible (1) or not (0).

*'''Additional fields''' : If needed, there are some additional fields that while not normally used can be utilized. Additional fields typically require looking up information in other tables (such as the course categories or context tables). The additional fields provide an alternative way of finding the course category context id. A bit of extra caution is recommended in using these additional fields. The list of additional fields includes:
:<code>context</code> - used to specify the name of the context name for each of the cohorts you are uploading.
:<code>category</code> - used to specify the name of the category name for each of the cohorts you are uploading. For example, the category name of a particular course category.
:<code>category_id</code> - used to specify the course category id (not idnumber) of the category for each of the cohorts you are uploading. For example, the course category id of a particular course category.
:<code>category_idnumber</code> - used to specify the course category idnumber (not id) of the category for each of the cohorts you are uploading. For example, the course category idnumber of a particular course category.
:<code>category_path</code> - used to specify the course category path of the category for each of the cohorts you are uploading. For example, the course category path of a particular course category.

== See also ==
* [[Cohorts]]
* [[Cohorts#Creating_cohorts_in_bulk|Creating cohorts in bulk]]

[[es:Subir cohortes]]
[[de:Globale Gruppen hochladen]]

Community hubs

2015-02-18T14:08:50Z

Ghillenb:

{{Managing a Moodle site}}
A community hub provides a directory of courses for public use or for private communities.
[[File:Community-hubs-flowchart.png|200px|thumb|left|Click to enlarge]]

The diagram shows the basic idea. The systems in this diagram are:

;Ordinary Moodle site: A typical Moodle site with teachers who want to download course templates and/or users who want to connect (enrol) with external communities
;Publishing site: A Moodle site that wants to make some of its courses available for download
;Community site: A Moodle site that provides courses that are enrollable
;Moodle Hub Server: A new Moodle plugin for listing registered courses that are ''downloadable'' or ''enrollable''. The default hub is at moodle.net, but there can be many others.

Community Hubs in Moodle 2.0 video:

<mediaplayer>http://www.youtube.com/watch?v=kFLDOcJ3cbg</mediaplayer>

==Downloadable courses==

# Sites that want to publish certain courses and make them downloadable can register them with one or more hub servers.
# The hub will check the data and make sure the course zip is downloadable, caching a copy locally. The hub may also have a security process to check the download for trojan horses, bad content, etc.
# The download process may trigger the backup process on the original server if it hasn't been done already.
# Later, Moodle users (who have permissions to do so) can connect to a hub to search for downloadable courses and choose one.
# The Moodle site downloads the file and makes it available to the Moodle user so they can now continue to restore it normally.

==Enrollable courses==

# Sites that want to publish certain courses for the public to enrol in can register them with one or more hub (including the main one at moodle.org).
# Later, any Moodle user can connect to a hub (via Community block in their site) to search and find courses they want to join.
# They click on a link to be sent to the other site so that they can enrol there.

==See also==

*[[Publishing a course]]
*[[Hub administration]]
*[[Hub FAQ]]
*[[Community finder block]]
*[[MNet]] - a Moodle network

[[Category:Hub]]

[[ja: コミュニティハブ]]
[[en:Community hubs]]
[[de:Community Hubs]]

2012-12-05T10:16:43Z

Ghillenb:

{{Security}}
==Update notifications==
[[File:Pluginsoverview.png|thumb|left|Checking for available updates via the plugins overview page]]An administrator can configure update notifications for both Moodle core code and any contributed plugins installed on the site (from the [http://moodle.org/plugins plugins directory]) in ''Settings > Site Administration > Server > Update notifications''.

If the automatic check for available updates is enabled and there is a new update available, a notification will be sent to all site admins via email and/or popup message (according to the admin's messaging preferences in their profile settings).

{{New features}}In Moodle 2.4 onwards, updates deployment i.e. the option to update installed plugins from within Moodle may be enabled by ticking the updateautodeploy checkbox. When updates are available, ''Install this update'' buttons are shown on the [[Plugins overview]] page (''Settings > Site Administration > Plugins > Plugins overview''). See [[Automatic updates deployment]] for more details.

An administrator can specify the required code maturity (stable, alpha, beta or release candidate) for update notifications, also whether notifications of new builds (normally released each week) are sent.

[[File:updates check button.png|thumb|Checking for available updates via the notifications page]]An admin can also check for available updates for contributed plugins installed on the site using the 'Check for available updates' button in ''Settings > Site Administration > Plugins > [[Installing plugins|Plugins overview]]''. Any updates available are highlighted, with further information and a download link in the notes column opposite the plugin.

Available updates for core code can also be checked via ''Settings > Site administration > Notifications''.

== How it works ==

# The information about available updates are available as a web service at download.moodle.org
# When ''Check for updates'' button is pressed (or daily via cron), your Moodle fetches information about available updates from the web service and stores it locally.
# The list of installed plugins is compared with the list of available updates. If a newer version of Moodle or a plugin is available, the Moodle informs site administrators.

When calling the web service, your site must provide its own version and the list of all installed add-ons. No sensitive data (like the location of your site, any user data etc) are submitted.

== Disabling update notifications ==

In a few circumstances (such as completely managed servers, which may have a lot of local modifications) it is desirable to not have the check for updates active. The feature may be disabled completely by adding the following code to the [[Configuration file|config.php file]]:

$CFG->disableupdatenotifications = true;

== Errors and exceptions ==

When experiencing an error, please turn debugging on. The debug info will contain additional information about the reason of the error.

=== Unable to fetch available updates data - unexpected cURL error ===

See the debug info for the actual cURL error number and the error text.

; cURL error 7 couldn't connect to host : Make sure that the site http://download.moodle.org is up and running at the moment. If it is down, your site can't call the web service to fetch the available updates info. Wait for the download.moodle.org site is up again and try to re-check.
; cURL error 60 (SSL certificate problem) : This suggests problems with the validation of the SSL certificate of the remote (moodle.org) site. See [[SSL certificate for moodle.org]] for more info.

This error may also raise if your Moodle is configured to run behind a mis-configured proxy server.

=== Unable to fetch available updates data - unexpected HTTP response code ===

See the debug info for the actual HTTP response code. On success, the HTTP response code is 200. All other response codes throw this error.

=== Unexpected version of the response format ===

This could happen if you check for updates during the major Moodle upgrade. Please try to re-check for available updates once you finish upgrading your Moodle.

[[de:Aktualisierungsmitteilung]]

Caching

2012-12-05T08:47:30Z

Ghillenb:

{{Performance}}{{New features}}
A cache is a collection of data that is kept on hand and made readily available in order to avoid costly fetching and moulding upon every request.

Moodle 2.4 saw the implementation of MUC Stage 1: Implement some core caching architecture.

Two links, that might be useful to anyone considering testing the new features 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]

==See also==

* Using Moodle [https://moodle.org/mod/forum/discuss.php?d=217195 MUC is here, now what?] forum discussion

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

{{stub}}
[[de:Caching]]