MoodleDocs - User contributions [en]

Using web services

2017-03-16T10:24:46Z

Harrysmith: /* Enabling protocols */

{{Web services}}
This document explains how an administrator can set up a web service for users to access a service. Each user will have a specific and unique security key (also known as a "token") to access the service.

== Enabling web services==
[[Image:Enable_web_service.jpg|thumb|Enabling web services]]
# Access ''Administration > Site administration > Advanced features''
# Check 'Enable web services' then click 'Save Changes'

Note: For security reasons, web services should only be enabled if you intend to make use of it.

== Enabling protocols ==
[[Image:Enable_protocol.jpg|thumb|left|Enabling protocols]]
Usually external applications that users wish to use dictate which protocols should be enabled.

# Access ''Administration > Site administration > Plugins > Web services > Manage protocols''
# Enable the protocols (SOAP, REST, XMLRPC, AMF, ...) as required

== Enabling web service function documentation ==
[[Image:Security keys and documentation.jpg|thumb|Security keys page with documentation link]]
Enabling web service function documentation (also on the Manage protocols page) results in user-specific web service documentation being available for each user on their [[Security keys]] page. This option is mainly useful to web service client developers. If nobody is creating a web service client, there is no need to enable this feature.

== Creating a service ==
If none of the pre-build web services match your needs, you can create a custom service i.e. select which of the standard web service functions are available via that service.

You can enable only the specific functions that you need to expose, so not compromising on security.
[[Image:Create a service.jpg|thumb|Creating a service|left]]
# Access ''Administration > Site administration > Plugins > Web services > External services''
# Click Add new custom service
#* 'Authorised users only' - If enabled, you will need to select the authorised users manually. Otherwise all users with appropriate permissions are allowed
#* 'Required capability' - If enabled, any user accessing the web service will be checked against this selected capability. (This is just an additional optional security layer.)
# Enter a name and check Enabled
# Click the button 'Add service'

==Adding functions to the service==
[[Image:Select a web service function.jpg|thumb|Adding functions to the service]]Your service is currently empty and doesn't do anything. Web service functions need to be added. Your choice will be dictated by what you allow the external application to do. For this example, select 'Create group'.

# Click 'Add functions' link
# Select 'create group' function and click the 'Add functions' button

''Note that deprecated functions can not be added to services although the ones that are already part of a service can remain there until they are removed from Moodle codebase.''

You should be back to the service functions list. 'Required capabilities' are indicated for each function. Users need the required capabilities to run a function. The function descriptions in the API Documentation can also give you more information about the required capabilities (''Administration > Site administration > Plugins > Web services > API Documentation'').

==Enabling capabilities==

The final step is to grant appropriate permissions. The following capabilities should be allowed:

* [[Capabilities/moodle/webservice:createtoken|moodle/webservice:createtoken]] - for allowing users to generate a security key
* [[Capabilities/webservice/rest:use | webservice/rest:use]], [[Capabilities/webservice/soap:use | webservice/soap:use]], [[Capabilities/webservice/xmlrpc:use | webservice/xmlrpc:use]], [[Capabilities/webservice/amf:use | webservice/amf:use]] which match the enabled protocols.
* The service ''Required capability'' if set (''Administration > Site administration > Plugins > Web services > Manage services >'''Edit''' link'').
* The required capabilities for the web service functions. These required capabilities are listed when you add a function to the service. For more information about roles and capabilities, read the [[Manage roles]] documentation.

Once done, the web service should be set up. Users should be able to [[Security keys|obtain a personal security key]].

= Alternative settings =

== Authorise only specific users==
[[Image:Authorised users link.jpg|thumb]] [[Image:Authorised user selection page.jpg|thumb]]
# ''Administration > Site Administration > Plugins > Web services > External Services''
# Select '''Authorised users''' link (the service must have been set as '''Authorised users only''' in the '''Edit''' link)
# Select some users and click '''Add'''

Moodle indicates if some capabilities need to be assigned to an authorised user. Moreover if you click on the authorised user fullname, you can set up some specific options: ''IP restriction'' and ''Valid until''.

== Create a token ==
[[Image:Create_token.jpg|thumb]]
This feature allows you to create a token for specific user. It can be useful if a user doesn't have the moodle/create:token capability. This is also the only way to create a token for an administrator. For security reason, tokens are not automatically generated in the administrator security keys page.

# ''Administration > Site Administration > Plugins > Web services > Manage tokens''
# Click on '''Add'''
# Select the created user and service
# Click on '''Saves changes'''

As you created a token for this user, you do not need to assign "''moodle/webservice:createtoken''" to him/her.
Finally, note that, as for authorised users, you can also set ''IP restriction'' and ''Valid until'' on a token.

== See also ==

*[http://www.joomdle.com/wiki/Preparing_Moodle_20#Setting_up_Moodle_Web_services Joomdle documentation about setting Moodle web services]

Using web services

2017-03-16T10:23:48Z

Harrysmith: /* Enabling protocols */

{{Web services}}
This document explains how an administrator can set up a web service for users to access a service. Each user will have a specific and unique security key (also known as a "token") to access the service.

== Enabling web services==
[[Image:Enable_web_service.jpg|thumb|Enabling web services]]
# Access ''Administration > Site administration > Advanced features''
# Check 'Enable web services' then click 'Save Changes'

Note: For security reasons, web services should only be enabled if you intend to make use of it.

== Enabling protocols ==
[[Image:Enable_protocol.jpg|thumb|Enabling protocols]]
Usually external applications that users wish to use dictate which protocols should be enabled.

# Access ''Administration > Site administration > Plugins > Web services > Manage protocols''
# Enable the protocols (SOAP, REST, XMLRPC, AMF, ...) as required

== Enabling web service function documentation ==
[[Image:Security keys and documentation.jpg|thumb|Security keys page with documentation link]]
Enabling web service function documentation (also on the Manage protocols page) results in user-specific web service documentation being available for each user on their [[Security keys]] page. This option is mainly useful to web service client developers. If nobody is creating a web service client, there is no need to enable this feature.

== Creating a service ==
If none of the pre-build web services match your needs, you can create a custom service i.e. select which of the standard web service functions are available via that service.

You can enable only the specific functions that you need to expose, so not compromising on security.
[[Image:Create a service.jpg|thumb|Creating a service|left]]
# Access ''Administration > Site administration > Plugins > Web services > External services''
# Click Add new custom service
#* 'Authorised users only' - If enabled, you will need to select the authorised users manually. Otherwise all users with appropriate permissions are allowed
#* 'Required capability' - If enabled, any user accessing the web service will be checked against this selected capability. (This is just an additional optional security layer.)
# Enter a name and check Enabled
# Click the button 'Add service'

==Adding functions to the service==
[[Image:Select a web service function.jpg|thumb|Adding functions to the service]]Your service is currently empty and doesn't do anything. Web service functions need to be added. Your choice will be dictated by what you allow the external application to do. For this example, select 'Create group'.

# Click 'Add functions' link
# Select 'create group' function and click the 'Add functions' button

''Note that deprecated functions can not be added to services although the ones that are already part of a service can remain there until they are removed from Moodle codebase.''

You should be back to the service functions list. 'Required capabilities' are indicated for each function. Users need the required capabilities to run a function. The function descriptions in the API Documentation can also give you more information about the required capabilities (''Administration > Site administration > Plugins > Web services > API Documentation'').

==Enabling capabilities==

The final step is to grant appropriate permissions. The following capabilities should be allowed:

* [[Capabilities/moodle/webservice:createtoken|moodle/webservice:createtoken]] - for allowing users to generate a security key
* [[Capabilities/webservice/rest:use | webservice/rest:use]], [[Capabilities/webservice/soap:use | webservice/soap:use]], [[Capabilities/webservice/xmlrpc:use | webservice/xmlrpc:use]], [[Capabilities/webservice/amf:use | webservice/amf:use]] which match the enabled protocols.
* The service ''Required capability'' if set (''Administration > Site administration > Plugins > Web services > Manage services >'''Edit''' link'').
* The required capabilities for the web service functions. These required capabilities are listed when you add a function to the service. For more information about roles and capabilities, read the [[Manage roles]] documentation.

Once done, the web service should be set up. Users should be able to [[Security keys|obtain a personal security key]].

= Alternative settings =

== Authorise only specific users==
[[Image:Authorised users link.jpg|thumb]] [[Image:Authorised user selection page.jpg|thumb]]
# ''Administration > Site Administration > Plugins > Web services > External Services''
# Select '''Authorised users''' link (the service must have been set as '''Authorised users only''' in the '''Edit''' link)
# Select some users and click '''Add'''

Moodle indicates if some capabilities need to be assigned to an authorised user. Moreover if you click on the authorised user fullname, you can set up some specific options: ''IP restriction'' and ''Valid until''.

== Create a token ==
[[Image:Create_token.jpg|thumb]]
This feature allows you to create a token for specific user. It can be useful if a user doesn't have the moodle/create:token capability. This is also the only way to create a token for an administrator. For security reason, tokens are not automatically generated in the administrator security keys page.

# ''Administration > Site Administration > Plugins > Web services > Manage tokens''
# Click on '''Add'''
# Select the created user and service
# Click on '''Saves changes'''

As you created a token for this user, you do not need to assign "''moodle/webservice:createtoken''" to him/her.
Finally, note that, as for authorised users, you can also set ''IP restriction'' and ''Valid until'' on a token.

== See also ==

*[http://www.joomdle.com/wiki/Preparing_Moodle_20#Setting_up_Moodle_Web_services Joomdle documentation about setting Moodle web services]

Competencies

2016-10-03T04:03:07Z

Harrysmith: /* How is it set up? */

{{Tracking progress}}
{{New features}}
== What are competencies?==

Competencies describe the level of understanding or proficiency of a learner in certain subject-related skills. Competency-based education (CBE), also known as Competency-based learning or Skills-based learning, refers to systems of assessment and grading where students demonstrate these competencies. In Moodle 3.1 it is possible to create and apply frameworks for evaluating students against competencies in Moodle.
*Video: [https://www.youtube.com/watch?v=6zzVgFcQToU| CBE for admins]
*Video: [https://www.youtube.com/watch?v=mxBaPnP0j1g| CBE for teachers]
*Video: [https://www.youtube.com/watch?v=QF7Bb3mN9tA| CBE for students]

==How is it set up?==

*Competencies may be enabled by an administrator in ''Site administration > Competencies''.
*Administrators can then set up competency frameworks and add competencies to them. See [[Competency frameworks]] for more information.
*They can then create learning plan templates, add competencies to them and assign learning plans to individual selected students or to whole cohorts. See [[Learning plans]] for more information.
*Teachers can add competencies to courses and course activities. They can view a [[Competency breakdown report |competency breakdown report]] from the Administration block and rate competencies.
*Staff with the relevant capabilities can review student learning plans and view any evidence of prior learning students submit. For more details see [[Competencies FAQ]].
*Students can view their learning plans, upload evidence of prior learning and request reviews. For more details see [[Competencies FAQ]].
*For those with the relevant capabilities, a new [[Learning plans block]] is available to be added to the dashboard (for example).

== Course competencies ==

*A course teacher can list which of the competencies they will be teaching in their course from ''Course administration > Course competencies.'' A teacher can add or remove competencies from a course here, and see which competencies have been linked to which activities. Clicking on the competency name will take the teacher to a grading page for that competency.
*A student can also see (but not change) the competencies linked to a course from ''Course administration > Course competencies'' and will also see their current rating for each competency.

===Manually rating course competencies===

A course teacher can rate the students against each of the course competencies from ''Course administration > Reports > Competency breakdown.'' Select a student from the menu ''(1)'' and then click on the desired competency ''(2)'':

[[File:compbreakdownreport2.png|thumb|600px|center]]

The page for that student will display and you can then change their rating from the dropdown ''(3)'':
[[File:cbrating.png|thumb|centre|600px]]

For more information, see [[Competencies FAQ]].

== Activity competencies ==

Competencies can be linked to activities. This means you can make sure that you have activities or resources for every competency in the course, by looking at the course competencies page and finding un-mapped competencies.

It is possible to map more than one competency to an activity, by selecting more than once from the competency drop down when setting up the activity.

It is possible to use activity completion to automatically complete - or add evidence to course competencies.

To add a competency to an activity

# Edit the settings for the activity
# In the competencies section, select one or more competencies from the list of course competencies
# If desired, set what to do upon activity completion - attach evidence, send for review or complete the competency

[[File:activity competencies.png|frame|center|Adding competencies to an activity]]

The activity will then be shown under the competency on the course competencies page

[[File:course competencies.png|frame|center|Course competency with linked activity]]

====Example of Activity completion with Activity competencies====
A student must demonstrate a skill four times before they achieve a competency:

*Create four activities (such as four assignments) with activity completion set to receiving a grade.
* Set a pass grade from the assignment setting screen.
*For assignments 2, 3 and 4, restrict access until the previous assignments have been completed.
*In the assignment settings for the final assignment, expand 'Course competencies', select the required competency and set 'Upon activity completion' to 'Complete the competency'.
* The student submits work as normal. The teacher grades work as normal. If all four assignments obtain a pass grade, the competency is automatically achieved.
[[File:studentviewcomp.png|frame|center|Student view of competency achieved.]]

==Backing up and restoring competencies==
Courses with competencies may be backed up to include the competencies. ''However, these will only be restored to a new site if the competencies already exist with the same ID numbers on the new site.''

== Statistics ==

Statistics are built into the various pages.

Student - view competencies in a course:

[[File:course-student.png|thumb|600px|center|Course competency progress for a student]]

Student - view their own learning plan:
[[File:plan-student.png|thumb|600px|center|Learning plans progress for a student]]

Teacher - view competencies in a course:
[[File:course-teacher.png|thumb|600px|center|Course competency statistics for a teacher]]

Manager - view progress for all plans in a template:
[[File:template-manager.png|thumb|600px|center|Learning Plan Template statistics for a manager]]

==See also==

* [[Competencies FAQ]]

[[Category:Competencies]]

[[es:Competencias]]

[[fr:Compétences]]
[[de:Kompetenzen]]

Transitioning to HTTPS

2016-09-01T09:17:32Z

Harrysmith: /* Setting up an SSL certificate */

{{Security}}
There are numerous benefits to running your moodle site using HTTPS. This increases the level of security especially involving sessions and passwords.

== Steps ==
=== Before you start ===
Check all the content you use supports https. You will not be able to embed HTTP content over HTTPS. If some content is only available over HTTP, you can convert it from a direct embedding to a link.

Make sure you have a staging environment. You will want to set up HTTPS the first time on a staging environment rather than updating your live site. It will take some time to convert to https and you will need to update content (see below).

=== Setting up an SSL certificate ===
The first thing you will need to do is acquire an SSL certificate. You can create these yourself, but this is only helpful for development purposes. Instead you will want to get your SSL certificate from a certificate authority, so that the certificate will be publicly verified.

The cost of certificates has been somewhat prohibitive, they come at various costs from a few dollars to hundreds of dollars per year. For the budget constrained, the "price is right" with a new initiative brought to us by the Internet Security Research Group (ISRG). Free domain-validated certificates can be acquired from [https://letsencrypt.org Let's Encrypt]. Let's Encrypt also tries to make the process of installing and managing certificates as painless as possible and there are numerous methods and clients available.

=== Setting up your server ===
Then you will need enable SSL on your web server to add your certificate. This process will vary depending on your web server of choice.

If you are using a proxy or load balancer, depending on your setup you will most likely want to set up the SSL certificate on your proxy server

=== Setting up your moodle ===

On a basic moodle site, it will be simple to set up https. Simply edit config.php and change http:// to https:// in $CFG->wwwroot.

However if you are using a proxy or load balancer, depending on your setup you may need to set $CFG->sslproxy to 1, and not use SSL on the moodle server. Then the load balancer or proxy server can communicate directly to your moodle site, but serve to the clients over SSL.

=== Updating content ===
You will need to change all embeded content from being requested over http. Links do not matter. But you will need to update images and iframes, scorm modules, and LTI external tools. You can modify external tools to open in a new window instead of in an iframe and they will work fine.

There is plans to work on a new tool to aid in this process. See MDL-46269 on the tracker.

Transitioning to HTTPS

2016-09-01T09:14:41Z

Harrysmith: /* Setting up an SSL certificate */

{{Security}}
There are numerous benefits to running your moodle site using HTTPS. This increases the level of security especially involving sessions and passwords.

== Steps ==
=== Before you start ===
Check all the content you use supports https. You will not be able to embed HTTP content over HTTPS. If some content is only available over HTTP, you can convert it from a direct embedding to a link.

Make sure you have a staging environment. You will want to set up HTTPS the first time on a staging environment rather than updating your live site. It will take some time to convert to https and you will need to update content (see below).

=== Setting up an SSL certificate ===
The first thing you will need to do is acquire an SSL certificate. You can create these yourself, but this is only helpful for development purposes. Instead you will want to get your SSL certificate from a certificate authority, so that the certificate will be publicly verified.

The cost of certificates has been somewhat prohibitive, they come at various costs from a few dollars to hundreds of dollars per year. For the budget constrained the "price is right" with a new initiative brought to us by the Internet Security Research Group (ISRG). Free domain-validated certificates can be acquired from [https://letsencrypt.org Let's Encrypt].

=== Setting up your server ===
Then you will need enable SSL on your web server to add your certificate. This process will vary depending on your web server of choice.

If you are using a proxy or load balancer, depending on your setup you will most likely want to set up the SSL certificate on your proxy server

=== Setting up your moodle ===

On a basic moodle site, it will be simple to set up https. Simply edit config.php and change http:// to https:// in $CFG->wwwroot.

However if you are using a proxy or load balancer, depending on your setup you may need to set $CFG->sslproxy to 1, and not use SSL on the moodle server. Then the load balancer or proxy server can communicate directly to your moodle site, but serve to the clients over SSL.

=== Updating content ===
You will need to change all embeded content from being requested over http. Links do not matter. But you will need to update images and iframes, scorm modules, and LTI external tools. You can modify external tools to open in a new window instead of in an iframe and they will work fine.

There is plans to work on a new tool to aid in this process. See MDL-46269 on the tracker.

filter generico

2016-08-03T01:20:50Z

Harrysmith: /* VideoEasy */

{{Infobox plugin
|type =filter
|entry = https://moodle.org/plugins/filter_generico
|tracker = https://github.com/justinhunt/moodle-filter_generico/issues
|discussion = https://moodle.org/mod/forum/discuss.php?d=261896
|maintainer = [[User:Justin Hunt]]
|float = right
}}
Using Generico (and Video Easy)

==Introduction==
In technical terms Generico and Video Easy are filters for Moodle. But that doesn't go very far towards describing how they can help you. In user speak, they allow an administrator to define reusable snippets of html/css and javascript that can be popped into Moodle html areas. These snippets are called templates. Simple templates can be used to display a welcome message with the current logged in user's name, an attractive green button that returns users to the main course page, a video player or an FAQ style accordian. More advanced templates have been used to make QR codes, text to speech widgets and image slideshows.

Whats so good about this? Well it gives you considerable ability to customize your Moodle site without having to resort to multiple plugins, or custom PHP coding. It also allows you to centralise and reuse common bits of html, such as disclaimers and copyright notices. Finally it provides a way to allow your users to perform tasks such as the embedding of iframe content from a specific site, without needing to give them permission to embed iframes generally.

Writing templates requires as much skill as the complexity of the template. But using templates that have already been made requires no particular skill at all. Both Generico and VideoEasy come with a collection of pre-made templates to help you get started.

== Whats the difference between Generico and VideoEasy? ==
They are very similar and from a template makers point of view are almost the same thing. Where they differ mainly is how and when Moodle chooses to apply a template to an HTML page, and how variables are passed to the template.

=== VideoEasy ===
VideoEasy works by looking for html links on the page. If the html link matches a file extension VideoEasy is registered for, it will replace the link with the processed template.

So a link to a video file with an .mp4 extension, could be replaced by an mp4 video player. Despite its name, VideoEasy is not limited to video at all. it is possible to register other file extensions too. For example it is possible to register the .pdf extension and replace .pdf links with a pdf viewer.

File extensions that VideoEasy should handle are registered at:
Site Administration -> Plugins -> Filters -> Video Easy -> General Settings

The actual template that should be used for a file extension is registered on the same page. This can be overridden at the course or activity level via the “settings” button on the “filter” page accessed from the activity instance’s settings menu. This allows different courses or activities to use different video players if necessary.

Variables can be passed to the template by appending parameters to the html link URL. So in the url http://mysite.com?favoritefruit=apple, the variable 'favoritefruit' will be populated with the value 'apple' and made available to the template as @@favoritefruit@@.

== Generico ==
Generico works a little differently to VideoEasy. Rather than act on links in the text area, it acts on specially formatted text blocks that look like this:
{GENERICO:type="greenbutton",text="Go Back"}

When it finds one of these, it replaces it with the processed template. A template author might be able to make these crafty little text blocks by hand, but it is not realistic for average users. So a special plugin is available for the Atto text editor which can prepare the Generico filter strings for the user.

=== Using a Generico template ===
There are two ways you might add a Generico template to a page.
i) Manually enter a Generico filter string on a page
ii) Selecting a Generico template from the Generico popup dialog on the Atto text editor.

In most cases you will use the latter, because it is simple and less prone to human error. Lets look at the example of a Generico template to display a pretty button with custom caption and link. In such a case the Generico filter if added by hand would look like this:
{GENERICO:type=prettybutton,caption="Go to Google",link="http://google.com"}

If however you used the Atto popup dialog, it would look like this:

But even after you have used the Atto Generico plugin to insert your Generico string on the page, it is still just a Generico string. It doesn't look anything like a button. This is because Generico processes the filter string only after the html area content is saved, and the page containing it is displayed.

The reason we call Generico templates … “templates” is that they are combined with some data to produce the final html snippet that is displayed on the page. In the case of the pretty button, this data was the caption and the url. When the template is created, placeholders called variables are inserted into it. Then when you add the template to a page you pass in the data, e.g. caption and url, and they will be merged with the template to create the html snippet. The Generico Atto text editor plugin will generate a simple form with a field (i.e. text area or dropdown list) for each variable to make it easier for the user.

=== Examining a simple Generico Template ===
So lets make a simple Generico template. Templates are defined in the site administration area. Each template will have an entry under:
site administration->plugins->filters->generico

By default there are 20 blank templates when Generico is installed, but it is possible to add more. Blank Generico templates do nothing, you have to fill them in before anything will happen. But its easy enough to make a new template that does something, because there are preset templates that can be used. Lets use the simplest one of all the “hello world” template. To do this:
i) open a blank template
ii) from the first control on the template settings page, choose “hello world” from the dropdown list of template presets.
iii) Scroll to the bottom and save the template.
Thats it, the template is created. Type the filter string “{GENERICO:type=helloworld}” into an html area (try a forum post or a page resource), Or choose/insert the filter string from the Generico atto editor plugin. When the page is displayed there should be a message saying “hello world [yourname].”

So what actually happened there? Well it goes like this….
a) Moodle is sending the page to the browser
b) It looks through the page for any Generico filter strings, and when it finds one:
i) it removes the filter string from the output
ii) it processes the filter string and replaces it with the processed output.
c) it sends the output to the page

The processing involves looking for variable placeholders in the template, and matching those with data in the filter string. When they match, variable placeholders in the template are swapped out for the filter string data. Then the processed template is returned to to the browser. This behaviour is explained in more detail later.

=== Importing and Exporting Templates ===
To allow you to share templates that you or others have created, it is possible to import and export them. On the top right of a template’s settings page, there is a green box titled “Bundle.” Clicking on the box will export the template to a text file of the same name as the template key. So for template “helloworld,” a hello world.txt file will be exported and the download begin immediately. To import such a file, you drag the text file onto the green bundle box. The border will turn blue. When the file is dragged and dropped there, the currently loaded template will be overwritten or filled in, with the imported content. The changes are not permanent however until the template is saved. So you will need to scroll to the bottom of the page and press the save button.

=== The Template Fields ===
The settings page for each template has X fields for Video Easy and 14 for Generico. The order and naming are a little different also. We can think of each field as being in one of 4 categories: General, HTML, Javascript and CSS. In the case of the hello world template there is no javascript or CSS. We just return some html. But we could add some CSS styles or even a javascript click event to the text if we wanted to. Lets look at each field in turn

a) The Template Key
b) The Template Name
c) The Template Instructions
d) The Template Body
e) The Template Body End
f) The Template AMD flag
g) The Template JQuery flag
h) The Template Require JS
i) The Template Script
j) The Template Upload JS
k) The Template Require CSS
l) The Template CSS
m) The Template Upload CSS
n) The Template Dataset
o) The Template Dataset Datavars

==== The Template Key ====
The template key is a unique identifier that is used in internal processing and is the most important part of a Generico filter string. The key should not contain any spaces or non alphanumeric characters(underscores are ok). The key is the “type” part of the Generico filter string. e.g in the prettybutton example we used earlier, the template key would be “pretty button.”
{GENERICO:type=prettybutton,caption="Go to Google",link="http://google.com"}

All other parts of the template you can change and the behaviour will change accordingly when the template is processed. But if the key is changed, all the filter strings that are live on the site for that template will no longer be processed. That is because the “type” will not be matched with any template’s key.

==== The Template Name ====
The template name is simply what is displayed around the site when referring to the template. i.e. on the settings pages and in the Atto text editor. Unlike the “key” you can include spaces and non alpha numeric characters here.

==== The Template Instructions ====
The template instructions will be displayed on the Atto text editor Generico insert form for the template. There is not much space there, so short instructions are best.

==== The Template Body ====
The template body is where you put any html that should be put on the page in place of the Generico filter string that is being processed. In the case of the “helloworld” example the template body looks like this:
Hello World @@USER:firstname@@

Note the use of a variable, in this case a preset variable that will return the current user’s first name. But the important thing here is that the actual replacement of the generic filter string takes place here. Whatever is in the body section will replace the string, albeit with any variables replaced by their actual value.

==== The Template Ends Section ====
This is only present for Generico. This will be processed in place of the “Template Body” section if the filter string’s type attribute is of the format ’type=[key]_end’ e.g {GENERICO:type=helloworld_end}. This is designed for use in the case where a template requires opening and closing tags. Lets take an example of a lightbox template that shows an image in a lightbox when a button was pressed. Two generico filter strings would be placed on the page, one for the opening tags, and another for the closing tags. So it might look like this:
{GENERICO:type=lightbox}
{GENERICO:type=lightbox_end}

The user could then insert an image between them using the standard Moodle “insert image” icon on the editor. The Generico Atto plugin is aware of the Template end field, and if it is not blank will automatically insert the end filter string on the page along with the main filter string.

==== The Template AMD flag ====
AMD is a javascript loading system that was put in place in Moodle in version 2.9. AMD loads any javascript dependencies for your template safely, and prevents naming and version conflicts with the dependencies of other templates and javascript on the same page. If your template does not involve javascript or its older than Moodle 2.9, then you won’t need to worry about this. If you do use javascript in the “template script” area (described later) then setting AMD to “yes” will make jQuery available to your script. If you load 3rd party libraries in the “template require JS” or “template upload JS” area you might have to choose whatever the 3rd party library recommends. A library that supports AMD will generally fail if you do not select “yes.” A library which does not support AMD will usually fail if you select “yes.”

==== The Template JQuery flag ====
When a third party library you load, or your own script, relies on JQuery you can force it to be loaded by setting this to “yes.” But you really should never do this. If you can find another way, then that would be better. (Warning: techy explanation follows) The reason for this, is that jQuery has versions and plugins. If another template or something else on the page has loaded a jQuery plugin, or requires a different version of jQuery, when you force load jQuery you will overwrite any jQuery (and plugins) that something else has already loaded. That something else will then fail. These conflicts can be hard to track down and are the very thing that the AMD system was designed to avoid. If you really need jQuery, and you can’t use AMD, try to use a theme that loads jQuery. Most of the nice themes like Essential do. Failing that, in the additional HTML area of moodle in the “HEAD” section, add your jQuery call. (Note that even loading jQuery using the additional HTML section of Moodle, you risk causing problems with other plugins that require jQuery.)

Devs here might wonder why Generico and VideoEasy don’t just use load jQuery using the $PAGE requirements manager in PHP. The problem is that the filter is often called after the page header has already been sent out to the browser. Trying to require jQuery via the $PAGE requirements manager at that point will cause an error.

==== The Template Require JS ====
If your template requires a 3rd party library, such as a library for making light boxes, then you can place the url for the library here. This is useful when the library makes itself available via a CDN (content distribution network). Because there is not requirement to supply the library itself with the template, just the URL, many presets and Generico/VideoEasy bundles load 3rd party libraries in this way.

When specifying the library’s URL, start with // (i.e. not https: or http:).

==== The Template Script ====
The template script if specified will be called once for each of your template’s filter strings on the page. It is common to use this to set up any event handlers or any DOM manipulation you need to do to init your template. For example if you are placing a button on the page that will open an image in a lightbox, you would add the html for the button in the “template body” and attach the event handler for the click event here. In this case you will generally need to give the button a class or an id attribute, and then select the element for that class or id in the script area. This is because the script is executed only after all the html has loaded on the page. To make it easy to use the same id or class in the “template script” and “template body” areas a special variable AUTOID is made available. This will provide a random and hopefully unique string that can be used as an element’s id or class, and that will be the same throughout the processing of a particular filter string.

Now at this point we really need to talk about variables. In your template you can use variables of your own definition, or you can use preset variables. AUTOID and USER:firstname are two examples of preset variables. Generico/VideoEasy will ensure they contain the correct data. You can declare your own custom variables too. Anything surrounded by double @@ marks will be treated as a variable. So in your template @@AUTOID@@ and @@FAVORITECOLOR@@ would be recognised as variables. If its a custom variable Generico will get the value from the filter string. VideoEasy will get custom variables’ values from the URL parameters. It is also possible to set default values for Generico/VideoEasy so that if not specified the default value will be used.

There is an important thing to note about using variables. Variables can be used in the “template body” and “template script” areas. But the processing is a little different. In the template body the variable @@FAVORITECOLOR@@ might be replaced by ‘pink.’ But in the template script it will be replaced by ‘opts[‘FAVORITECOLOR’].’

So in the “template body” you can place variables any way you choose and they will be swapped straight out for the value. But in “template script” you have to be careful NOT to write something like this:
var elem = $(‘#@@AUTOID@@’);

this will fail because post processing it will look like this:
var elem = $(‘#opts[‘AUTOID’]’);

Instead you should write this:
var elem = $(‘#’ + @@AUTOID@@);

This will work and will lead to something like this:
var elem = $(‘#’ + opts[‘AUTOID’]);

You might be wondering why we have to do it this way for the script. The reason is that the script file will be cached be Moodle. By using the opts variable in place of the literal value of the variable, caching will work nicely and the user will never be served up old content (or someone else’s content).

==== The Template Upload JS ====
The upload js area allows the administrator to upload a javascript file that will be loaded in the same way that the “template require js” file is loaded. It can be used in addition to the template require js file and is useful when you need more than one 3rd party library file, or when you want the javascript file loaded from the Moodle server and not from a CDN or other internet source.

==== The Template Require CSS ====
If your template requires a 3rd party CSS file, then you can place the url for the library here. When specifying the library’s URL, start with // (i.e. not https: or http:).

==== The Template CSS ====
Specify any custom CSS for your template here. Unfortunately you cannot use template variables in the custom css area. The custom CSS is loaded quite late and the late application of styles is noticeable by the user. If this is a concern, save your custom css declarations to a file and upload them into the “template upload CSS” area.

==== The Template Upload CSS ====
Similar to the “Template upload js” area, the “Template upload css” area allows the template author to upload a 3rd party CSS file. This is useful when the file should be accessed from the local server, or when the CSS styles should be applied earlier than those specified in “custom css” are.

==== The Template Dataset ====
It is also possible to set a custom SQL script which will be executed server side and the resulting data returned to your template. The SQL script will be called using Moodle’s $DB->get_records_sql() function. See: https://docs.moodle.org/dev/Data_manipulation_API#moodle_database::get_records_sql.28.29

If there is only a single record returned, the record will be available for use in the body area of the template using the following syntax @@DATASET:[fieldname]@@.
e.g
template dataset: “SELECT * FROM {user} WHERE id = 37;”
template body: User 37’s first name is @@DATASET:firstname@@, don’t forget it.

Whether one record or many are returned, if you specify a dataset then a @@DATASET@@ variable will be available to your template’s custom javascript. This will be an array of objects, each object representing one of the records that were returned. In the process of conversion from a PHP array of objects to an javascript array of objects, the order/index of the objects in the array appears to be modified, and so cannot be relied upon.

==== The Template Dataset Variables ====
Template variables do not work in the template dataset. This is because the get_records_sql api has its own template system. The first parameter to the function is the SQL statement. When you place question marks in the SQL statement, i.e. ‘?’ , Moodle recognises that as a variable. Variable values are passed in the second parameter to the function. Moodle will swap out each question mark for one of the values passed in the second parameter. Generic uses this system and allows you to specify a comma separated list of variable values in the Template Dataset Variables field. You can specify Generico template variables here, which gives this a lot of power. Lets demonstrate this by rewriting the above example to return the currently logged in user’s information.
template dataset: “SELECT * FROM {user} WHERE id = ?;”
template dataset vars: @@USER:id@@
template body: User @@USER:id@@’s first name is @@DATASET:firstname@@, don’t forget it.

Actually this is trivial because we already have access to the currently logged in user’s information via the Generico @@USER:xx@@ variable. But it demonstrates how to pull a dataset from the database using Generico template variables. You can use @@USER:xx@@, @@COURSE:xx@@ or any of the preset variables, and in addition can use variables which you have defined yourself.

Note that there are no ajax calls to get the data. When the filter is parsed the data will be fetched, and after that it will not be fetched again.

NB A bug in the current implementation of Generico means that only the first of the set of variables specified in the Dataset variables is actually made available to the plugin.

[[Category:Filter]]

Git for Administrators

2015-12-06T23:38:27Z

Harrysmith: /* Installing a contributed extension from its Git repository */

{{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 [[:dev:Git for developers|Git for developers guide]].

To get the most of Git it is worth making the effort to understand its basic concepts - see the section below. It can be a bit of a steep 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_30_STABLE origin/MOODLE_30_STABLE (3)
$ git checkout MOODLE_30_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_30_STABLE and set it to track the remote branch MOODLE_30_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_30_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 3.0.
<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_30_STABLE origin/MOODLE_30_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 3.0. 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 issuing 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/MOODLE_27_STABLE
remotes/origin/MOODLE_28_STABLE
remotes/origin/MOODLE_29_STABLE
remotes/origin/MOODLE_30_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_30_STABLE origin/MOODLE_30_STABLE
fatal: git checkout: updating paths is incompatible with switching branches.
Did you intend to checkout 'origin/MOODLE_30_STABLE' which can not be resolved as commit?
</pre>

Now it is wise to add 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 ==

* [[Windows installation using Git]]
* [[Git for Mac]]
* [[:dev:Moodle versions]]
* For fixing a Tracker Issue (MDL) / Forking Moodle / CONTRIButing code [[:dev:User:Sam_Hemelryk/My_Moodle_Git_workflow|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]
* [http://moodle.org/mod/forum/discuss.php?d=168094 GIT help needed]
* [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://gitref.org/ Git Reference]
* [http://progit.org/book/ Pro Git book]

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

Debugging

2015-04-07T16:09:51Z

Harrysmith: /* In config.php */

{{Developer tools}}
Debugging messages can be enabled by an administrator in ''Administration > Site administration > Development > Debugging''.

Debugging messages are intended to help diagnose problems and/or help Moodle developers. If you have a problem with your Moodle site and ask for help in a Moodle.org forum, a developer may ask you to turn debug messages on, in order to locate the cause of the problem. By default Moodle does not show any error messages at all. If you are having problems (e.g. blank screens or incomplete screens) turning on debugging is usually the first thing to try.

==Debugging settings==
Here are the settings on the Debugging page:

===Debug messages===
The default is none, your choices are:

;NONE : Do not show any errors or warnings (Default)
;ALL : Show all reasonable PHP debug messages
;MINIMAL : Show only fatal errors
;NORMAL : Show warnings, errors and notices
;DEVELOPER : extra Moodle debug messages for developers

There is rarely any advantage in going to Developer level, unless you are a developer, in which case it is strongly recommended.

Once you have got the error message, and copied and pasted it somewhere. HIGHLY RECOMMENDED to turn Debug back to NONE. Debug messages can give clues to a hacker as to the setup of your site.

===Display debug messages===

There is an option to choose whether to display error messages or simply record them in the server logs.

===Debug email sending===

Determines whether or not to enable verbose debug information during sending of email messages to SMTP server.

===Performance info===

The Performance info option determines whether performance info will be included in the footer of the standard theme (and some other themes). Performance info includes the time for the page to load, the amount of memory used to generate the page, cpu usage, load, and the record cache hit/miss ration.

If you add
<code php>
define('MDL_PERF', true);
define('MDL_PERFDB', true);
define('MDL_PERFTOLOG', true);
define('MDL_PERFTOFOOT', true);
</code>
to your config.php file, then it will also count database queries. (This has to be in config.php, because Moodle starts doing DB queries before it loads the config information in the database!

===Show origin of language strings===

Helps with [[:dev:Translation|translation]] and also with [[Language customization]]. Sometimes <code>?strings=1</code> should be added; other times <code>&strings=1</code>. See the Wikipedia article [http://en.wikipedia.org/wiki/Query_string Query string] for details.

===Show validator links===
Be careful, read the warning.

===Show page information===
To show page information printed in the page footer.

==What to do if you cannot get to the admin screens==

If the error is stopping you even getting to the admin screens to turn on debugging, then you can set the debugging setting manually.

===Try typing the URL directly===

The debug settings are at the URL <code><nowiki>http://.../admin/settings.php?section=debugging</nowiki></code> on your server. Sometimes that URL will work, even though the pages you need to go to get there (for example the site front page) do not. So it is worth trying to enter that URL directly.

===In config.php===

In [[Configuration file|config.php]] you can uncomment lines (delete the // at the start of the line) under Section 7 to enable debugging for all or just specific users:

<code php>
//=========================================================================
// 7. SETTINGS FOR DEVELOPMENT SERVERS - not intended for production use!!!
//=========================================================================
//
// Force a debugging mode regardless the settings in the site administration
// @error_reporting(E_ALL | E_STRICT); // NOT FOR PRODUCTION SERVERS!
// @ini_set('display_errors', '1'); // NOT FOR PRODUCTION SERVERS!
// $CFG->debug = (E_ALL | E_STRICT); // === DEBUG_DEVELOPER - NOT FOR PRODUCTION SERVERS!
// $CFG->debugdisplay = 1; // NOT FOR PRODUCTION SERVERS!
//
// You can specify a comma separated list of user ids that that always see
// debug messages, this overrides the debug flag in $CFG->debug and $CFG->debugdisplay
// for these users only.
// $CFG->debugusers = '2';
</code>

Remember to comment those lines again (reinsert the // at the start of the line) when you have finished diagnosing your problem.

'''NOTE 1''': do not try to modify the config database table directly, it will not work because the values are cached in MUC.

'''NOTE 2''': if you find your config.php does not have the above settings (you have a cut down approx 30 lines config.php) look for a "config-dist.php" file that contains the full details. I would suggest transferring your details in the current config.php file you have into the full config file and renaming that one to "config.php".

==See also==

* Developers can also use [http://xdebug.org/ XDEBUG] (Installed as a module on the Apache server) to further dig into the code, step by step using an [http://xdebug.org/docs/remote XDEBUG client application]. Probably, as part of their favorite IDE. For example: [http://php.netbeans.org/ NetBeans], [http://www.jetbrains.com/phpstorm/ phpStorm] or...

[[es:Depuración]]
[[fr:Débogage]]

Debugging

2015-04-07T16:08:22Z

Harrysmith: /* In config.php */

{{Developer tools}}
Debugging messages can be enabled by an administrator in ''Administration > Site administration > Development > Debugging''.

Debugging messages are intended to help diagnose problems and/or help Moodle developers. If you have a problem with your Moodle site and ask for help in a Moodle.org forum, a developer may ask you to turn debug messages on, in order to locate the cause of the problem. By default Moodle does not show any error messages at all. If you are having problems (e.g. blank screens or incomplete screens) turning on debugging is usually the first thing to try.

==Debugging settings==
Here are the settings on the Debugging page:

===Debug messages===
The default is none, your choices are:

;NONE : Do not show any errors or warnings (Default)
;ALL : Show all reasonable PHP debug messages
;MINIMAL : Show only fatal errors
;NORMAL : Show warnings, errors and notices
;DEVELOPER : extra Moodle debug messages for developers

There is rarely any advantage in going to Developer level, unless you are a developer, in which case it is strongly recommended.

Once you have got the error message, and copied and pasted it somewhere. HIGHLY RECOMMENDED to turn Debug back to NONE. Debug messages can give clues to a hacker as to the setup of your site.

===Display debug messages===

There is an option to choose whether to display error messages or simply record them in the server logs.

===Debug email sending===

Determines whether or not to enable verbose debug information during sending of email messages to SMTP server.

===Performance info===

The Performance info option determines whether performance info will be included in the footer of the standard theme (and some other themes). Performance info includes the time for the page to load, the amount of memory used to generate the page, cpu usage, load, and the record cache hit/miss ration.

If you add
<code php>
define('MDL_PERF', true);
define('MDL_PERFDB', true);
define('MDL_PERFTOLOG', true);
define('MDL_PERFTOFOOT', true);
</code>
to your config.php file, then it will also count database queries. (This has to be in config.php, because Moodle starts doing DB queries before it loads the config information in the database!

===Show origin of language strings===

Helps with [[:dev:Translation|translation]] and also with [[Language customization]]. Sometimes <code>?strings=1</code> should be added; other times <code>&strings=1</code>. See the Wikipedia article [http://en.wikipedia.org/wiki/Query_string Query string] for details.

===Show validator links===
Be careful, read the warning.

===Show page information===
To show page information printed in the page footer.

==What to do if you cannot get to the admin screens==

If the error is stopping you even getting to the admin screens to turn on debugging, then you can set the debugging setting manually.

===Try typing the URL directly===

The debug settings are at the URL <code><nowiki>http://.../admin/settings.php?section=debugging</nowiki></code> on your server. Sometimes that URL will work, even though the pages you need to go to get there (for example the site front page) do not. So it is worth trying to enter that URL directly.

===In config.php===

In [[Configuration file|config.php]] you can uncomment lines (delete the // at the start of the line) under Section 7 to enable debugging for all or just specific users:

<code php>
//=========================================================================
// 7. SETTINGS FOR DEVELOPMENT SERVERS - not intended for production use!!!
//=========================================================================
//
// Force a debugging mode regardless the settings in the site administration
// @error_reporting(E_ALL | E_STRICT); // NOT FOR PRODUCTION SERVERS!
// @ini_set('display_errors', '1'); // NOT FOR PRODUCTION SERVERS!
// $CFG->debug = (E_ALL | E_STRICT); // === DEBUG_DEVELOPER - NOT FOR PRODUCTION SERVERS!
// $CFG->debugdisplay = 1; // NOT FOR PRODUCTION SERVERS!
//
// You can specify a comma separated list of user ids that that always see
// debug messages, this overrides the debug flag in $CFG->debug and $CFG->debugdisplay
// for these users only.
// $CFG->debugusers = '2';
</code>

Remember to comment those lines again (reinsert the // at the start of the line) when you have finished diagnosing your problem.

'''NOTE 1''': do not try to modify the config database table directly, it will not work because the values are cached in MUC.
'''NOTE 2''': if you find your config.php does not have the above settings (a cut down approx 30 lines config.php) look for a "config-dist.php" file that contains the full details. I would suggest transferring your details in the current config.php file you have into the full config file and renaming that one to "config.php".

==See also==

* Developers can also use [http://xdebug.org/ XDEBUG] (Installed as a module on the Apache server) to further dig into the code, step by step using an [http://xdebug.org/docs/remote XDEBUG client application]. Probably, as part of their favorite IDE. For example: [http://php.netbeans.org/ NetBeans], [http://www.jetbrains.com/phpstorm/ phpStorm] or...

[[es:Depuración]]
[[fr:Débogage]]

Debugging

2015-04-07T14:02:26Z

Harrysmith: /* In config.php */

{{Developer tools}}
Debugging messages can be enabled by an administrator in ''Administration > Site administration > Development > Debugging''.

Debugging messages are intended to help diagnose problems and/or help Moodle developers. If you have a problem with your Moodle site and ask for help in a Moodle.org forum, a developer may ask you to turn debug messages on, in order to locate the cause of the problem. By default Moodle does not show any error messages at all. If you are having problems (e.g. blank screens or incomplete screens) turning on debugging is usually the first thing to try.

==Debugging settings==
Here are the settings on the Debugging page:

===Debug messages===
The default is none, your choices are:

;NONE : Do not show any errors or warnings (Default)
;ALL : Show all reasonable PHP debug messages
;MINIMAL : Show only fatal errors
;NORMAL : Show warnings, errors and notices
;DEVELOPER : extra Moodle debug messages for developers

There is rarely any advantage in going to Developer level, unless you are a developer, in which case it is strongly recommended.

Once you have got the error message, and copied and pasted it somewhere. HIGHLY RECOMMENDED to turn Debug back to NONE. Debug messages can give clues to a hacker as to the setup of your site.

===Display debug messages===

There is an option to choose whether to display error messages or simply record them in the server logs.

===Debug email sending===

Determines whether or not to enable verbose debug information during sending of email messages to SMTP server.

===Performance info===

The Performance info option determines whether performance info will be included in the footer of the standard theme (and some other themes). Performance info includes the time for the page to load, the amount of memory used to generate the page, cpu usage, load, and the record cache hit/miss ration.

If you add
<code php>
define('MDL_PERF', true);
define('MDL_PERFDB', true);
define('MDL_PERFTOLOG', true);
define('MDL_PERFTOFOOT', true);
</code>
to your config.php file, then it will also count database queries. (This has to be in config.php, because Moodle starts doing DB queries before it loads the config information in the database!

===Show origin of language strings===

Helps with [[:dev:Translation|translation]] and also with [[Language customization]]. Sometimes <code>?strings=1</code> should be added; other times <code>&strings=1</code>. See the Wikipedia article [http://en.wikipedia.org/wiki/Query_string Query string] for details.

===Show validator links===
Be careful, read the warning.

===Show page information===
To show page information printed in the page footer.

==What to do if you cannot get to the admin screens==

If the error is stopping you even getting to the admin screens to turn on debugging, then you can set the debugging setting manually.

===Try typing the URL directly===

The debug settings are at the URL <code><nowiki>http://.../admin/settings.php?section=debugging</nowiki></code> on your server. Sometimes that URL will work, even though the pages you need to go to get there (for example the site front page) do not. So it is worth trying to enter that URL directly.

===In config.php===

In [[Configuration file|config.php]] you can uncomment lines (delete the // at the start of the line) under Section 7 to enable debugging for all or just specific users:

<code php>
//=========================================================================
// 7. SETTINGS FOR DEVELOPMENT SERVERS - not intended for production use!!!
//=========================================================================
//
// Force a debugging mode regardless the settings in the site administration
// @error_reporting(E_ALL | E_STRICT); // NOT FOR PRODUCTION SERVERS!
// @ini_set('display_errors', '1'); // NOT FOR PRODUCTION SERVERS!
// $CFG->debug = (E_ALL | E_STRICT); // === DEBUG_DEVELOPER - NOT FOR PRODUCTION SERVERS!
// $CFG->debugdisplay = 1; // NOT FOR PRODUCTION SERVERS!
//
// You can specify a comma separated list of user ids that that always see
// debug messages, this overrides the debug flag in $CFG->debug and $CFG->debugdisplay
// for these users only.
// $CFG->debugusers = '2';
</code>

Remember to comment those lines again (reinsert the // at the start of the line) when you have finished diagnosing your problem.

NOTE: do not try to modify the config database table directly, it will not work because the values are cached in MUC.

==See also==

* Developers can also use [http://xdebug.org/ XDEBUG] (Installed as a module on the Apache server) to further dig into the code, step by step using an [http://xdebug.org/docs/remote XDEBUG client application]. Probably, as part of their favorite IDE. For example: [http://php.netbeans.org/ NetBeans], [http://www.jetbrains.com/phpstorm/ phpStorm] or...

[[es:Depuración]]
[[fr:Débogage]]

Moodle migration

2015-02-21T08:59:56Z

Harrysmith: /* Migrating a complete Moodle site - method 2 */

{{Installing Moodle}}
There may be times when you need to move your Moodle site from one server to another. For example, moving a Moodle site from shared hosting service's server to a dedicated server.

:''Tip:'' One common migration mistake is to forget to update the details in the migrated Moodle's ''[[Configuration file|config.php]]'' file.

==Migrating a complete Moodle site - method 1==

This involves moving a whole site from one server to another. If you are changing the domain/IP address to the new server you need to do these steps:
* '''Maintenance mode'''. Place your current Moodle site into [[Maintenance mode]] Site Administration>Server>Maintenance Mode to prevent any further additions to the Moodle database. Don't let administrators login during the migration as they are not affected by the maintenance mode setting.
* '''Backup your current Moodle 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 from command line on Unix to backup the database:
<pre>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</pre>
* '''Change your Moodle URL'''. If you have a new URL, you'll need to change this in the Moodle database to the new server. This is needed as links to pictures, files, etc are stored as absolute links and will reference the old <code>$CFG->wwwroot</code> value. So when loading a mysql backup dump of the Moodle server into mysql on another server the absolute referenced links will be broken. There are two methods of doing this:
:(a) The first method changes the Moodle URL using the Moodle script ''replace.php'' while your site is currently running just before you backup the Moodle database. Point your browser to <nowiki>yourserver.com/admin/tool/replace/index.php</nowiki> or in older versions <nowiki>http://yourserver.com/admin/replace.php</nowiki>

:Enter the url for your old server (<nowiki>http://oldserver.com/</nowiki>) and new server (<nowiki>http://newserver.com/</nowiki>) and it will fix the mysql tables. You will also need to clear out any cached links by restarting your webserver. Now, take another backup of the Moodle database - this one will have the correct URLs.

:(b) The second method is to backup the Moodle database first, then use the search and replace feature of your text editor (or use a unix tool like sed) to replace the old URL with the new one in the mysql backup file. Here is an example sed command:

: <code>#sed -e 's/oldserver.com/newserver.com/g' oldmysqldump.sql > newmysqldump.sql</code>

:''NOTE:'' This second method will not replace text in blocks because they are stored base64 encoded in the database, so any links in blocks will not be fixed. Therefore you should consider using the replace tool after you migrate if you use this second method.
:''TIP:'' You may want to check the mysqldump file to see how the old server was referenced.
:After changing the URL, restore the mysql database
*'''Copy the database back up files to the new server and restore into the new database server'''.
:Once you have created the new database on the new server:
<pre>mysql -p new_database < moodle-database.sql</pre>
:For other databases, follow their instructions for restoring a backup.
* '''Copy the Moodle software'''. You will need to copy the Moodle code itself to the new server (this is the Moodle folder found in your webroot folder e.g. /var/www or public_html). If you want you can upgrade the code to the latest version at this point by downloading the latest code from the Moodle site, copying over your config.php file and any plugins that you might have installed. See [[Upgrading]].
* '''If you are changing the url or the new server has a different ip address, you will need to change <code>$CFG->wwwroot</code>'''. In your (possibly new) Moodle directory, change the <code>$CFG->wwwroot</code> variable in the ''config.php'' file for the new server.
* '''Copy data directory contents (moodledata)'''. Copy the contents of your data directory (check for the value in <code>$CFG->dataroot</code>) to the new server. If you'll use an FTP client, the transfer of the <code>filedir</code> folder must be in '''BINARY''' mode or the files will get corrupted in the process.
* '''Review moodledata permissions and ownership'''. Check also that ownership and permissions remain the same on the new dataroot folder and change the value if you have changed its location on the new server. Do the same for the new moodle code folder.
* '''Test the migration'''. To test the new install, access Moodle using your browser and the new server's URL. When you have tested that a number of links in the courses work, take the new Moodle site out of maintenance mode. If you have upgraded the Moodle code, you will go through the upgrade process when you first access the site.
'''See also''': Forum discussion on [http://moodle.org/mod/forum/discuss.php?d=85812 migrating Moodle's data directory on a Windows system].

==Migrating a complete Moodle site - method 2==

Do you have shell access on both servers? If so, the following method is a very quick and efficient method to migrate a Unix based site.

It is also useful for creating snapshots or test sites.
*Set up a new empty database on the '''new''' server.
*Place your existing Moodle site into maintenance mode.
*Login to shell on the '''old''' existing server.
*Use rsync to copy '''moodledata''' and '''public_html''' or '''moodle''' folders (or whatever directory your Moodle install is in) to the new server - execute (replacing caps with your details; SOURCE = the directory you want to copy) for each directory:
::<code>rsync -av -e ssh SOURCE/ USERNAME@NEW_SERVER.COM:/PATH/TO/DESTINATION/</code>
*Dump existing database and move and import into database on new server by executing:
::<code>mysqldump --allow-keywords --opt -uMySQL_USERNAME -pPASSWORD DATABASE | ssh USER@DOMAIN "mysql -uMySQL_USERNAME -pPASSWORD DATABASE"</code>
*On the '''new server''', update '''config.php''' with relevant details where applicable (e.g. database name and user details, the wwwroot and the dataroot).
*Check ownership and permissions are correct on both moodle code and moodledata directories.
*To fix any internal Moodle links, login to your "new" Moodle install on your new server and use the [[Search and replace]] admin tool to search and replace the old url for the new one in the database.
*Make sure everything is working.

Takes about 15 minutes for a small site. However, transferring several Gigabytes of data for a larger site can take hours depending on your network connection and hard drive read/write speed.

When you are happy all has gone well, set up redirects/make DNS changes if required, take new site out of maintenance mode and "switch off" old site.

*If you are switching the ip address from the old server to the new one, you will need to turn off the old server before firing up the new one to avoid ip addressing conflicts and confusion!

==Other points to consider==
===Changed URL image links set to old site===
So you built your Moodle Server with a <nowiki>http//192.168.0.1/Moodle</nowiki> address. Then you changed the URL for your site to <nowiki>http://OurMoodle.org/Moodle</nowiki>. You changed the Moodle config file so the CFGs point to the new paths, but your images still point to the old url.

One simple, quick solution is to use the Replace script in Moodle to fix this. Login as admin and enter <nowiki>http://OurMoodle.org/admin/tool/replace/index.php</nowiki> in your browser address bar (or <nowiki>http://OurMoodle.com/admin/replace.php</nowiki> in older versions). Use the two form boxes to change <nowiki>http://192.168.0.1/</nowiki> to <nowiki>http://OurMoodle.org/</nowiki>.

This replace function is only supported on Moodle sites that run on MySQL or Postgres databases. See MDL-26597 and MDL-35099.

===Upgrade Moodle===

When migrating Moodle it is often a good idea to take the opportunity to upgrade Moodle to the latest version. If you manage your own server, follow the instructions in [[Upgrading | upgrading moodle]], otherwise check if your host can upgrade for you.

===Restoring a single course across servers===

You may need to restore a single course from an old site to a new one, especially if you are testing the migration. When restoring a Moodle backup file to Moodle on a different server than the one used to create the backup, the absolute referenced links to files maybe broken. To fix this problem open the ''backup-coursename.zip'' file and edit the ''moodle.xml'' file replacing links with <code>$@FILEPHP@$</code>.

For example, replace <nowiki>http://yourserver.com/file.php/243/</nowiki> with <code>$@FILEPHP@$</code>

When the file is restored it will use the correct file path for the new course.

===DNS & Masquerading changes===

You may have had to change the DNS entries for the new Moodle site. If you have done so, it will take some time for the changes to replicate, so be patient. If your server is located behind a firewall, you may also have to change your firewall rules to allow access to the new server. See the [[Masquerading | masquerading docs]].

===Internal and external access===

If you have a set up where your Moodle site can be accessed via a network and via the internet, ensure you check that the new site can be accessed internally and externally.

==See also==

* [[Site backup]]
* [[Site restore]]
* [[Backup and restore FAQ]]
* [http://www.youtube.com/watch?v=sFCXvRx20Bs Moving Moodle to a new server video]
* [http://tracker.moodle.org/browse/MDL-35099 Convert hidden search/replace script into a proper core admin tool] Tracker issue

Using Moodle forum discussions:
* [http://moodle.org/mod/forum/discuss.php?d=62959 Changing Moodle URL]
* [http://moodle.org/mod/forum/discuss.php?d=57477 Changing site address]
* [http://moodle.org/mod/forum/discuss.php?d=76704 Upgrading whilst migrating]
* [http://moodle.org/mod/forum/discuss.php?d=65450 Internal and external access]
* [http://moodle.org/mod/forum/discuss.php?d=111807 Migrated Moodle to New Server But Can't Login]
* [http://moodle.org/mod/forum/discuss.php?d=228436 Replace script returns "Service Unavailable"]

[[es:Migración de Moodle]]
[[fr:Migration de Moodle]]
[[ja:Moodle移行]]
[[de:Moodle-Migration]]

WebDAV repository

2013-06-06T07:52:52Z

Harrysmith: /* Options */

{{Repositories}}
Web-based Distributed Authoring and Versioning (WebDAV) is a set of methods based on the Hypertext Transfer Protocol (HTTP) that facilitates collaboration between users in editing and managing documents and files stored on World Wide Web servers.

A WebDAV repository can be enabled by a site administrator in ''Settings > Site administration > Plugins > Repositories > Manage repositories''.

==WebDAV configuration==

After enabling the WebDAV repository, a repository instance can be created in ''Settings > Site administration > Plugins > Repositories > WebDAV repository''.

[[Image:Webdav config.png]]

===Options===
WebDAV type: Choose from HTTP or HTTPS connection

WebDAV server: The server name

WebDAV path: The path to webdav directory

Authentication: We currently only support HTTP Basic Authentication

WebDAV server port: The webdav server port

WebDAV server user: HTTP Basic authentication username

WebDAV server password: HTTP Basic authentication password

For example, if you are going to add a webdav server at http://webdavserver.tld/path/to/dir, you should use following options:
WebDAV type: HTTP
WebDAV Server: webdavserver.tld

== Configuring WebDAV on Microsoft Windows Server 2003 R2 (Service Pack 2), IIS V6.0 ==

=== Configure Windows Server 2003 ===

First we need to install WebDAV on the server. ''Note:'' when you promote a basic Windows Server 2003 installation to an application server, it installs various IIS 6 components but WebDAV isn’t one of them.

==== Install and Enable WebDAV on the Server ====

To install WebDAV on the IIS 6 machine, use Add or Remove Programs in Control Panel and run the Windows Components Wizard. You can find WebDAV under '''Application Server -> Internet Information Services -> World Wide Web Service -> WebDAV Publishing'''.

Once WebDAV is installed it needs to be enabled. Check the WebDAV option under the Web Service Extensions node in IIS Manager.

=== Configure IIS ===

Configuring a new virtual directory in IIS is a two-step process:

#Create a new virtual directory using the Virtual Directory wizard
#Configure the access permissions on the new virtual directory

==== Create New Virtual Directory ====
#Open IIS and right-click on your Moodle website. Select '''New -> Virtual Directory'''... from the pop-up menu. [[Image:New_virtual_directory.png|200 px|Menu option required for creating new virtual directory]]
#Select '''New -> Virtual directory...''' from the pop-up menu. The '''Create New Virtual Directory Wizard''' is displayed. [[Image:Wizard_intro.png|200 px|IIS Virtual Directory Creation Wizard]]
#Call the new virtual directory '''Moodledata'''. [[Image:Name_directory.png|200 px|alt text]]
#Specify the path to the Moodledata directory. [[Image:Choose_path.png|200 px|Choosing path to folder on server]]
#Ensure the new virtual directory has '''Read''', '''Write''' and '''Browse''' permissions. [[Image:Directory_permissions.png|200 px|Specifying directory permissions]]
#Press the Finish button to create the new virtual directory.

==== Configuring Virtual Directory Properties ====

#Right-click on the new virtual directory and select Properties from the pop-up menu. [[Image:Check_properties.png|200 px|Checking new virtual directory properties]]
#Ensure that '''Read''', '''Write''', '''Directory browsing''', and '''Log visits''' are checked. Ensure '''Index this resource''' is unchecked. [[Image:Properties_view.png|200 px|Virtual directory properties correctly configured]]
#Click on the '''Directory Security''' tab and press the '''Authentication and access control''' Edit... button [[Image:Authentication_tab.png|200 px|Directory Security authentication and access control]]
#Authenticated access configuration will depend on your needs. Basic access will require you to uncheck '''Enable anonymous access''' and check '''Basic authentication (password is sent in clear text)'''. You may get a warning about security: [[Image:Authentication_warn.png|200 px|Directory security warning]]
#Your new virtual directory is ready for testing. [[Image:Final_view.png|200 px|New virtual directory ready for use]]

=== Testing WebDAV on Windows XP ===

WebDAV needs to be enabled on any client machines that will be used to create and manage content for Moodle. Windows XP has a built-in WebDAV client service that needs to be enabled:

#Open the '''Services''' console under '''Administrative Tools''' and find the '''WebClient''' service.
#Double-click on this service to open its '''Properties''' sheet.
#Change the '''Startup Type''' to ''Automatic'', then click the Start button to start the service.

''Note:'' Internet Explorer 8.0 no longer supports web folders. See [http://blogs.msdn.com/b/askie/archive/2009/03/20/open-as-web-folder-not-in-the-internet-explorer-8-file-open-dialog.aspx this blog post from David Conner] for details. Instead, you will need to map a network drive (instructions on mapping a network drive are also given in David's blog post).

WebDAV path: /path/to/dir/

==Repository permissions==

This repository is accessible by default to administrators, course creators, teachers, editing teachers and managers, but not to guests or students. This [[Capabilities/repository/webdav:view|capability]] can be changed to control access to users with specific roles.

==See also==

* MDL-22663

[[Category:Site administration]]
[[de:WebDAV Repository]]

IMS Enterprise

2013-05-30T23:11:37Z

Harrysmith: /* See also */

{{Enrolment}}
Location: IMS Enterprise file edit settings link in ''Site administration > Plugins > Enrolments > Manage enrol plugins''

'''IMS Enterprise''' is an international standard XML file format which may be used to specify enrolments/unenrolments in courses, as well as course information and user information.

==Format overview==

Below is a simple guide to the basic structure of a typical IMS Enterprise data file. Much more information is available on the [http://www.imsglobal.org/enterprise/ IMS Enterprise official website].

You may like to read the [https://github.com/moodle/moodle/blob/master/enrol/imsenterprise/entv1p1_conformance_summary.html conformance summary] which describes which IMS data elements this plugin can process.

==Basic guide to IMS Enterprise file format==

For any IMS-style enrolment you need a <group> tag which specifies the course, a <person> tag which specifies the user account, and a <membership> tag containing <member> tags which specify a person's role within a given course.

Remember that the numeric keys used in the Moodle databases are not the interoperable data - a student data system is never going to know in advance that Joe is the 20th user added to the Moodle database - so those aren't the keys exchanged in this type of data.

Typically a course would have a reference code as well as a name, so let's assume its code is MOODLE101. If you require a new course to be placed in a category other than the default, you can specify that using the <orgunit> tag. To define your course you could use

<group>
<sourcedid>
<source>MyDataSystem</source>
<id>MOODLE101</id>
</sourcedid>
<description>
<short>Moodle 101</short>
<long>Moodle 101: Course Name</long>
</description>
<org>
<orgunit>CATEGORY</orgunit>
</org>
</group>

The enrolment script will look for a course with code MOODLE101, and (optionally) create it if it doesn't exist, the plugin also allows you to map between group tags and the course shortname, fullname and summary fields. Similarly for the person - let's assume it's "jmoodle":

<person>
<sourcedid>
<source>MyDataSystem</source>
<id>jmoodle</id>
</sourcedid>
<userid>jmoodle</userid>
<name>
<fn>Joe Moodle</fn>
<n>
<family>MOODLE</family>
<given>JOE</given>
</n>
</name>
</person>

If Joe doesn't already have an account, the script can (optionally) create an account for him.

Let's now look at the membership, adding the person to the course:

<membership>
<sourcedid>
<source>MyDataSystem</source>
<id>MOODLE101</id>
</sourcedid>
<member>
<sourcedid>
<source>MyDataSystem</source>
<id>jmoodle</id>
</sourcedid>
<role roletype="01">
<status>1</status>
<extension><cohort>unit 2</cohort></extension>
</role>
</member>
</membership>

The IMS Enterprise specification does offer a facility for specifying start/end dates for enrolments, so those can be included using the <timeframe> tag if needed.

If a person is already added to a group within the course, the script won't actually modify that. If they are not grouped, however, then the specified grouping will be applied.

==Automatic creation of new courses==

If required, the IMS Enterprise enrolment plugin can create new courses for any it finds in the IMS data but not in Moodle's database.

Courses are first queried by their "idnumber" - an alphanumeric field in Moodle's course table, which can specify the code used to identify the course in the Student Information System (for example). If that is not found, the course table is searched for the "short description", which in Moodle is the short course identifier as displayed in the breadcrumbs etc. (In some systems these two fields may well be identical.) Only when that search has failed can the plugin optionally create new courses.

Any newly-generated courses are HIDDEN when created. This is to prevent the possibility of students wandering into completely empty courses that the teacher may be unaware of.

==Unenrolling students/teachers==

If required, the Enterprise data can add as well as remove course enrolments - for students and for teachers. If this setting is turned on, then Moodle will carry out unenrolments when specified in the data. Note, as of Moodle 2, you must use IMSEnterprise to remove members that have been added by the plugin. You cannot manually delete a member.

There are three ways of unenrolling students within the IMS data:

* A <member> element which specifies the given student and course, and with the "recstatus" attribute of the <role> element set to 3 (which means "delete"). THIS IS NOT YET IMPLEMENTED IN THE MOODLE PLUGIN.
* A <member> element which specifies the given student and course, and with the <status> element set to 0 (which means "inactive").

The third method is slightly different. It does not require this config setting to be activated, and can be specified well in advance of the unenrolment date:

* A <member> element which specifies a <timeframe> for the enrolment can specify the begin and/or end dates for enrolment of this particular student. These dates are loaded into Moodle's enrolment data table if present, and so after the end-date, a student will no longer be able to access that particular course.

==See also==

* [http://www.imsglobal.org/enterprise/ IMS Enterprise specification] - the official site
* [https://github.com/moodle/moodle/blob/master/enrol/imsenterprise/entv1p1_conformance_summary.html Conformance summary] - summarises the parts of the specification which Moodle makes use of
* [https://studydirect.sussex.ac.uk/downloads/imsenterprise.php Minted IMS Enterprise enrolment plugin] - An extension of the ims enterprise enrolment plugin developed in the [http://www.sussex.ac.uk/minted minted project]

[[fr:Fichier IMS Enterprise]]
[[de:Einschreibung über IMS Enterprise Datei]]

Moodle migration

2012-08-13T19:49:19Z

Harrysmith: /* Migrating a complete Moodle site - method 2 */

{{Installing Moodle}}
There may be times when you need to move your Moodle site from one server to another. For example, moving a Moodle site from shared hosting service's server to a dedicated server.

:''Tip:'' One common migration mistake is to forget to update the details in the migrated Moodle's ''[[Configuration file|config.php]]'' file.

==Migrating a complete Moodle site - method 1==

This involves moving a whole site from one server to another. If you are changing the domain/IP address to the new server you need to do these steps:
* '''Maintenance mode'''. Place your current Moodle site in maintenance mode to prevent any further additions to the Moodle database. Don't let administrators login during the migration as they are not affected by the maintenance mode setting.
* '''Backup your current Moodle database'''. Do this by following the instructions in the [[Upgrading | upgrading Moodle]] or [[Site backup]] page. This will give you a text file containing the mysql dump.
* '''Copy the Moodle software'''. You will need to copy the Moodle code itself to the new server - upgrade the code to the latest version if you can.
* '''Change <code>$CFG->wwwroot</code>'''. In your (possibly new) Moodle directory, change the <code>$CFG->wwwroot</code> variable in the ''config.php'' file for the new server.
* '''Copy data directory contents (moodledata)'''. Copy the contents of your data directory (check for the value in <code>$CFG->dataroot</code>) to the new server.
* '''Review moodledata permissions'''. Check also that permissions remain the same on the new dataroot folder and change the value if you have changed its location on the new server.
* '''Change your Moodle URL'''. If you have a new URL, you'll need to change this in the Moodle database to the new server. This is needed as links to pictures, files, etc are stored as absolute links and will reference the old <code>$CFG->wwwroot</code> value. So when loading a mysql backup dump of the Moodle server into mysql on another server the absolute referenced links will be broken. There are two methods of doing this:
:(a) The first method changes the Moodle URL using the Moodle script ''replace.php'' while your site is currently running just before you backup the Moodle database. Point your browser to <nowiki>yourserver.com/admin/tool/replace/index.php</nowiki> or in older versions <nowiki>http://yourserver.com/admin/replace.php</nowiki>

:Enter the url for your old server (<nowiki>http://oldserver.com/</nowiki>) and new server (<nowiki>http://newserver.com/</nowiki>) and it will fix the mysql tables. You will also need to clear out any cached links by restarting your webserver. Now, take another backup of the Moodle database - this one will have the correct URLs.

:(b) The second method is to backup the Moodle database first, then use the search and replace feature of your text editor (or use a unix tool like sed) to replace the old URL with the new one in the mysql backup file. Here is an example sed command:

: <code>#sed -e 's/oldserver.com/newserver.com/g' oldmysqldump.sql > newmysqldump.sql</code>

:''NOTE:'' This second method will not replace text in blocks because they are stored base64 encoded in the database, so any links in blocks will not be fixed. Therefore you should consider using the replace tool after you migrate if you use this second method.

:''TIP:'' You may want to check the mysqldump file to see how the old server was referenced.
:After changing the URL, restore the mysql database
* '''Test the migration'''. To test the new install, access Moodle using your browser and the new server's URL. When you have tested that a number of links in the courses work, take the new Moodle site out of maintenance mode.
'''See also''': Forum discussion on [http://moodle.org/mod/forum/discuss.php?d=85812 migrating Moodle's data directory on a Windows system].

==Migrating a complete Moodle site - method 2==

Do you have shell access on both servers? If so, the following method is a very quick and efficient method to migrate a Unix based site.

It is also useful for creating snapshots or test sites.
*Set up a new empty database on the '''new''' server.
*Place your existing Moodle site into maintenance mode.
*Login to shell on the '''old''' existing server.
*Use rsync to copy '''moodledata''' and '''public_html''' (or whatever directory your Moodle install is in) to the new server - execute (replacing caps with your details; SOURCE = the directory you want to copy) for each directory:
::<code>rsync -av -e ssh SOURCE/ USERNAME@NEW_SERVER.COM:/PATH/TO/DESTINATION/</code>
*Dump existing database and move and import into database on new server by executing:
::<code>mysqldump --allow-keywords --opt -uMySQL_USERNAME -pPASSWORD DATABASE | ssh USER@DOMAIN "mysql -uMySQL_USERNAME -pPASSWORD DATABASE"</code>
*On the '''new server''', update '''config.php''' with relevant details.
*To fix any internal Moodle links, login to your "new" Moodle install on your new server and use the [[Search and replace]] admin tool to search and replace the old uri for the new.
*Make sure everything is working.</code>

Takes about 15 minutes.

When you are happy all has gone well, set up redirects/make DNS changes if required, take new site out of maintenance mode and "switch off" old site.

==Other points to consider==
===Changed URL image links set to old site===
So you built your Moodle Server with a <nowiki>http//192.168.0.1/Moodle address. Then you changed the URL for your site to http://OurMoodle.org/Moodle . You changed the Moodle config file so the CFGs point to the new paths. But your images point to the old url. </nowiki>

<nowiki>One simple, quick solution. Login as admin and put <nowiki>OurMoodle.org/admin/tool/replace/index.php</nowiki> or in older versions <nowiki>http://OurMoodle.com/admin/replace.php</nowiki> in your browser address bar. Use the two form boxes to change http://192.168.0.1/ to http://OurMoodle.org/ .</nowiki>

===Upgrade Moodle===

When migrating Moodle it is often a good idea to take the opportunity to upgrade Moodle to the latest version. If you manage your own server, follow the instructions in [[Upgrading | upgrading moodle]], otherwise check if your host can upgrade for you.

===Restoring a single course across servers===

You may need to restore a single course from an old site to a new one, especially if you are testing the migration. When restoring a Moodle backup file to Moodle on a different server than the one used to create the backup, the absolute referenced links to files maybe broken. To fix this problem open the ''backup-coursename.zip'' file and edit the ''moodle.xml'' file replacing links with <code>$@FILEPHP@$</code>.

For example, replace <nowiki>http://yourserver.com/file.php/243/</nowiki> with <code>$@FILEPHP@$</code>

When the file is restored it will use the correct file path for the new course.

===DNS & Masquerading changes===

You may have had to change the DNS entries for the new Moodle site. If you have done so, it will take some time for the changes to replicate, so be patient. If your server is located behind a firewall, you may also have to change your firewall rules to allow access to the new server. See the [[Masquerading | masquerading docs]].

===Internal and external access===

If you have a set up where your Moodle site can be accessed via a network and via the internet, ensure you check that the new site can be accessed internally and externally.

==See also==

* [[Site backup]]
* [[Site restore]]
* [[Backup and restore FAQ]]
* [http://www.youtube.com/watch?v=sFCXvRx20Bs Moving Moodle to a new server video]

Using Moodle forum discussions:
* [http://moodle.org/mod/forum/discuss.php?d=62959 Changing Moodle URL]
* [http://moodle.org/mod/forum/discuss.php?d=57477 Changing site address]
* [http://moodle.org/mod/forum/discuss.php?d=76704 Upgrading whilst migrating]
* [http://moodle.org/mod/forum/discuss.php?d=65450 Internal and external access]
* [http://moodle.org/mod/forum/discuss.php?d=111807 Migrated Moodle to New Server But Can't Login]

[[fr:Migration de Moodle]]
[[ja:Moodle移行]]
[[de:Moodle-Migration]]

Moodle migration

2008-10-23T00:41:46Z

Harrysmith: /* Migrating a complete Moodle site - method 2 */

There may be times when you need to move your Moodle site from one server to another, for example, moving from shared hosting to a dedicated server - this is known as migrating your Moodle site. One common mistake to watch out for is to remember to update the relevant details in your Moodle ''config.php'' file.

==Migrating a complete Moodle site - method 1==

This involves moving a whole site from one server to another. If you are changing the domain/IP address to the new server you need to do these steps:
* '''Maintenance mode'''. Place your current Moodle site in maintenance mode to prevent any further additions to the Moodle database. Don't let administrators login during the migration as they are not affected by the maintenance mode setting.
* '''Backup your current Moodle database'''. Do this by following the instructions in the [[Upgrading | upgrading Moodle]] page. This will give you a text file containing the mysql dump.
* '''Copy the Moodle software'''. You will need to copy the Moodle code itself to the new server - upgrade the code to the latest version if you can.
* '''Change <code>$CFG->wwwroot</code>'''. In your (possibly new) Moodle directory, change the <code>$CFG->wwwroot</code> variable in the ''config.php'' file for the new server.
* '''Copy data directory contents (moodledata)'''. Copy the contents of your data directory (check for the value in <code>$CFG->dataroot</code>) to the new server. Check also that permissions remain the same on the new dataroot folder and change the value if you have changed its location on the new server.
* '''Change your Moodle URL'''. If you have a new URL, you'll need to change this in the Moodle database to the new server. This is needed as links to pictures, files, etc are stored as absolute links and will reference the old <code>$CFG->wwwroot</code> value. So when loading a mysql backup dump of the Moodle server into mysql on another server the absolute referenced links will be broken. There are two methods of doing this:
:(a) The first method changes the Moodle URL using the Moodle script ''replace.php'' while your site is currently running just before you backup the Moodle database. Point your browser to <nowiki>http://yourserver.com/admin/replace.php</nowiki>

:Enter the url for your old server (<nowiki>http://oldserver.com/</nowiki>) and new server (<nowiki>http://newserver.com/</nowiki>) and it will fix the mysql tables. You will also need to clear out any cached links by restarting your webserver. Now, take another backup of the Moodle database - this one will have the correct URLs.

:(b) The second method is to backup the Moodle database first, then use the search and replace feature of your text editor (or use a unix tool like sed) to replace the old URL with the new one in the mysql backup file. Here is an example sed command:

: <code>#sed -e 's/oldserver.com/newserver.com/g' oldmysqldump.sql > newmysqldump.sql</code>

:''TIP:'' You may want to check the mysqldump file to see how the old server was referenced.
:After changing the URL, restore the mysql database
* '''Test the migration'''. To test the new install, access Moodle using your browser and the new server's URL. When you have tested that a number of links in the courses work, take the new Moodle site out of maintenance mode.
'''See also''': [http://moodle.org/mod/forum/discuss.php?d=85812 Forum discussion] on migrating Moodle's data directory on a Windows system.

==Migrating a complete Moodle site - method 2==

Do you have shell access on both servers? If so, the following method is a very quick and efficient method to migrate a *nix based site.

It is also useful for creating snapshots or test sites.
*Set up a new empty database on the '''new''' server.
*Place your Moodle site into maintenance mode.
*Login to shell on the '''old''' server.
*Use rsync to copy '''moodledata''' and '''public_html''' (or whatever directory your Moodle install is in) to the new server - execute (replacing caps with your details; SOURCE = the directory you want to copy) for each directory:
::<code>rsync -av -e ssh SOURCE/ USERNAME@NEW_SERVER.COM:/PATH/TO/DESTINATION/</code>
*Dump existing database and move and import into database on new server by executing:
::<code>mysqldump --allow-keywords --opt -uMySQL_USERNAME -pPASSWORD DATABASE | ssh USER@DOMAIN "mysql -uMySQL_USERNAME -pPASSWORD DATABASE"</code>
*On the '''new server''', update '''config.php''' with relevant details.
*To fix any internal Moodle links, login to your "new" Moodle install on your new server and use '''admin/replace.php''' to search and replace the old uri for the new.
*Make sure everything is working.

Takes about 15 minutes.

When you are happy all has gone well, set up redirects/make DNS changes if required, take new site out of maintenance mode and "switch off" old site.

==Other points to consider==

===Upgrade Moodle===

When migrating Moodle it is often a good idea to take the opportunity to upgrade Moodle to the latest version. If you manage your own server, follow the instructions in [[Upgrading | upgrading moodle]], otherwise check if your host can upgrade for you.

===Restoring a single course across servers===

You may need to restore a single course from an old site to a new one, especially if you are testing the migration. When restoring a Moodle backup file to Moodle on a different server than the one used to create the backup, the absolute referenced links to files maybe broken. To fix this problem open the ''backup-coursename.zip'' file and edit the ''moodle.xml'' file replacing links with <code>$@FILEPHP@$</code>.

For example, replace <nowiki>http://yourserver.com/file.php/243/</nowiki> with <code>$@FILEPHP@$</code>

When the file is restored it will use the correct file path for the new course.

===DNS & Masquerading changes===

You may have had to change the DNS entries for the new Moodle site. If you have done so, it will take some time for the changes to replicate, so be patient. If your server is located behind a firewall, you may also have to change your firewall rules to allow access to the new server. See the [[Masquerading | masquerading docs]].

===Internal and external access===

If you have a set up where your Moodle site can be accessed via a network and via the internet, ensure you check that the new site can be accessed internally and externally.

==See also==

Using Moodle forum discussions:
* [http://moodle.org/mod/forum/discuss.php?d=62959 Changing Moodle URL]
* [http://moodle.org/mod/forum/discuss.php?d=57477 Changing site address]
* [http://moodle.org/mod/forum/discuss.php?d=76704 Upgrading whilst migrating]
* [http://moodle.org/mod/forum/discuss.php?d=65450 Internal and external access]

[[Category:Installation]]

[[fr:Migration de Moodle]]
[[nl:Moodle verhuizen]]
[[ja:Moodle移行]]

Moodle migration

2008-04-24T02:29:17Z

Harrysmith: Reordered content for focus, added a second method, removed link as not relevant ot focus of page IMHO

There may be times when you need to move your Moodle site from one server to another, for example, moving from shared hosting to a dedicated server - this is known as migrating your Moodle site. One common mistake to watch out for is to remember to update the relevant details in your Moodle ''config.php'' file.

==Migrating a complete Moodle site - method 1==

This involves moving a whole site from one server to another. If you are changing the domain/IP address to the new server you need to do these steps:
* '''Maintenance mode'''. Place your current Moodle site in maintenance mode to prevent any further additions to the Moodle database. Don't let administrators login during the migration as they are not affected by the maintenance mode setting.
* '''Backup your current Moodle database'''. Do this by following the instructions in the [[Upgrading | upgrading Moodle]] page. This will give you a text file containing the mysql dump.
* '''Copy the Moodle software'''. You will need to copy the Moodle code itself to the new server - upgrade the code to the latest version if you can.
* '''Change <code>$CFG->wwwroot</code>'''. In your (possibly new) Moodle directory, change the <code>$CFG->wwwroot</code> variable in the ''config.php'' file for the new server.
* '''Copy data directory contents (moodledata)'''. Copy the contents of your data directory (check for the value in <code>$CFG->dataroot</code>) to the new server. Check also that permissions remain the same on the new dataroot folder and change the value if you have changed its location on the new server.
* '''Change your Moodle URL'''. If you have a new URL, you'll need to change this in the Moodle database to the new server. This is needed as links to pictures, files, etc are stored as absolute links and will reference the old <code>$CFG->wwwroot</code> value. So when loading a mysql backup dump of the Moodle server into mysql on another server the absolute referenced links will be broken. There are two methods of doing this:
:(a) The first method changes the Moodle URL using the Moodle script ''replace.php'' while your site is currently running just before you backup the Moodle database. Point your browser to <nowiki>http://yourserver.com/admin/replace.php</nowiki>

:Enter the url for your old server (<nowiki>http://oldserver.com/</nowiki>) and new server (<nowiki>http://newserver.com/</nowiki>) and it will fix the mysql tables. You will also need to clear out any cached links by restarting your webserver. Now, take another backup of the Moodle database - this one will have the correct URLs.

:(b) The second method is to backup the Moodle database first, then use the search and replace feature of your text editor (or use a unix tool like sed) to replace the old URL with the new one in the mysql backup file. Here is an example sed command:

: <code>#sed -e 's/oldserver.com/newserver.com/g' oldmysqldump.sql > newmysqldump.sql</code>

:'''Tip''': You may want to check the mysqldump file to see how the old server was referenced.
:After changing the URL, restore the mysql database
* '''Test the migration'''. To test the new install, access Moodle using your browser and the new server's URL. When you have tested that a number of links in the courses work, take the new Moodle site out of maintenance mode.
'''See also''': [http://moodle.org/mod/forum/discuss.php?d=85812 Forum discussion] on migrating Moodle's data directory on a Windows system.

==Migrating a complete Moodle site - method 2==

Do you have shell access on both servers? If so, the following method is a very quick and efficient method to migrate a *nix based site.

It is also useful for creating snapshots or test sites.
*Set up a new empty database on the '''new''' server.
*Place your Moodle site into maintenance mode.
*Login to shell on the '''old''' server.
*Use rsync to copy '''moodledata''' and '''public_html''' (or whatever directory your Moodle install is in) to the new server - execute (replacing caps with your details; SOURCE = the directory you want to copy) for each directory:
::<code>rsync -av -e ssh SOURCE/ USERNAME@NEW_SERVER.COM:/PATH/TO/DESTINATION/</code>
*Dump existing database and move and import into database on new server by executing:
::<code>mysqldump --allow-keywords --opt -uMySQL_USERNAME -pPASSWORD DATABASE | ssh USER@DOMAIN "mysql -uMySQL_USERNAME -pPASSWORD DATABASE"</code>
*On the '''new server''', update '''config.php''' with relevant details.
*To fix any internal Moodle links, login to your "new" Moodle install on your new server and use '''admin/replace.php''' to search and replace the old uri for the new.
*Make sure everything is working.

Takes about 15 minutes.

When happy all has gone well, set up redirects/make DNS changes if required, take new site out of maintenance mode and "switch off" old site.

==Other points to consider==

===Upgrade Moodle===

When migrating Moodle it is often a good idea to take the opportunity to upgrade Moodle to the latest version. If you manage your own server, follow the instructions in [[Upgrading | upgrading moodle]], otherwise check if your host can upgrade for you.

===Restoring a single course across servers===

You may need to restore a single course from an old site to a new one, especially if you are testing the migration. When restoring a Moodle backup file to Moodle on a different server than the one used to create the backup, the absolute referenced links to files maybe broken. To fix this problem open the ''backup-coursename.zip'' file and edit the ''moodle.xml'' file replacing links with <code>$@FILEPHP@$</code>.

For example, replace <nowiki>http://yourserver.com/file.php/243/</nowiki> with <code>$@FILEPHP@$</code>

When the file is restored it will use the correct file path for the new course.

===DNS changes===

You may have had to change the DNS entries for the new Moodle site. If you have done so, it will take some time for the changes to replicate, so be patient.

===Internal and external access===

If you have a set up where your Moodle site can be accessed via a network and via the internet, ensure you check that the new site can be accessed internally and externally.

==See also==

Using Moodle forum discussions:
* [http://moodle.org/mod/forum/discuss.php?d=62959 Changing Moodle URL]
* [http://moodle.org/mod/forum/discuss.php?d=57477 Changing site address]
* [http://moodle.org/mod/forum/discuss.php?d=76704 Upgrading whilst migrating]
* [http://moodle.org/mod/forum/discuss.php?d=65450 Internal and external access]

[[Category:Installation]]

[[fr:Migration de Moodle]]
[[nl:Moodle verhuizen]]

Upgrading

2007-04-01T10:59:30Z

Harrysmith: /* 3. Your database */

Moodle is designed to upgrade cleanly from any earlier version to any later version. Please refer to [[Upgrading to Moodle 1.6]], [[Upgrading to Moodle 1.7]] or [[Upgrading to Moodle 1.8]] for particular considerations related to features of the version you are upgrading to.
__TOC__
When upgrading a Moodle installation you should follow these steps:

==Check the system requirements==
Spend some time re-reading the [[Installing Moodle | installation documentation]]. Check the system requirements for the version you are upgrading to in ''Administration > Server > [[Environment]]''.

== Backup important data ==

Although it is not strictly necessary, it is always a good idea to make a backup of any production system before a major upgrade, just in case you need to revert back to the older version for some reason. In fact, it's a good idea to automate your server to backup your Moodle installation daily, so that you can skip this step.

There are three areas that need backing up:

=== 1. The Moodle software directory itself ===

Make a separate copy of these files before the upgrade, so that you can retrieve your config.php and any modules you have added like themes, languages etc

=== 2. Your data directory ===

This is where uploaded content resides (such as course resources and student assignments) so it is very important to have a backup of these files anyway. Sometimes upgrades may move or rename directories within your data directory.

=== 3. Your database ===

Most Moodle upgrades will alter the database tables, adding or changing fields. Each database has different ways to backup. One way of backing up a MySQL database is to 'dump' it to a single SQL file. The following example shows Unix commands to dump the database called "moodle":

mysqldump -u username -p -C -Q -e -a moodle > moodle-backup-2007-04-01.sql

Substitute your database user account for username. The -p flag will prompt you for the password for the username specified by -u.

If your database host is different from the host you want to execute the backup command (usually the web server), you have to specify it with the -h option to mysqldump:

mysqldump -u username -p -h databasehost -C -Q -e -a moodle > moodle-backup-2007-04-01.sql

You can also use the "Export" feature in Moodle's optional "MySQL Admin" web interface to do the same thing on all platforms. This interface can be downloaded from http://download.moodle.org/modules/integrations.php. It is an integration of PHPMyAdmin for the Moodle administration interface.

== Install the new Moodle software ==

=== Using a downloaded archive ===

Do not overwrite an old installation unless you know what you are doing ... sometimes old files can cause problems in new installations. The best way is to rename the current Moodle directory to something else, then unpack the new Moodle archive into the old location.

mv moodle moodle.backup
tar xvzf moodle-1.1.tgz

Next, copy across your config.php and any other plugins such as custom themes:

cp moodle.backup/config.php moodle
cp -pr moodle.backup/theme/mytheme moodle/theme/mytheme

=== Using CVS ===

You can use CVS for updating or upgrading your Moodle.
First you need to do a CVS checkout in your (empty) Moodle root directory.

'''For Linux servers'''

To do a CVS checkout of Moodle, you first have to logon to the Moodle CVS server.

<nowiki>cvs -d:pserver:anonymous@moodle.cvs.sourceforge.net:/cvsroot/moodle login</nowiki>
No password for anonymous, so just hit the Enter button.

Go to the directory where you want the Moodle root to come and type

<nowiki>cvs -z3 -d:pserver:anonymous@moodle.cvs.sourceforge.net:/cvsroot/moodle co -r MOODLE_18_STABLE moodle</nowiki>
(where MOODLE_18_STABLE is the desired version)

To update, just go into the Moodle root directory and update to the new files:

cvs update -dP
To update to a new version type in the following and change 18 to whatever newest version upgrade number is
cvs -Q update -dP -r MOODLE_18_STABLE

Make sure you use the "d" parameter to create new directories if necessary, and the "P" parameter to prune empty directories.

'''For Windows servers'''

You can use Tortoise CVS to do the initial checkout and the updates.

If you have been editing Moodle files, watch the messages very closely for possible conflicts. All your customised themes and non-standard plugins will be untouched.

Don't forget to visit the admin page after the CVS update proces has completed.

== Finishing the upgrade ==

The last step is to trigger the upgrade processes within Moodle.

To do this just visit the admin page of your installation e.g. ''<nowiki>http://example.com/moodle/admin</nowiki>''

It doesn't matter if you are logged in as admin or not. If you are upgrading from some older versions you would not be able to login before the upgrade anyway.

Moodle will automatically detect the new version and perform all the database or filesystem upgrades that are necessary. If there is anything it can't do itself (very rare) then you will see messages telling you what you need to do.

Assuming all goes well (no error messages) then you can start using your new version of Moodle and enjoy the new features!

==See also==

*Using Moodle [http://moodle.org/mod/forum/view.php?id=28 Installation problems] forum
*[[Upgrading to Moodle 1.6]]
*[[Installing Moodle]]
*[[Installation FAQ]]
*[http://otaru-jc.ac.jp/hagley/howtoupgrademoodlewithcpanel.swf How to upgrade Moodle with cpanel tutorial].
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=26731&parent=125858 Using cvs] forum discussion
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=56915 Upgrading from 1.5.2 to 1.7] forum discussion
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=56991 Upgrade nightmares.... any help appreciated] forum discussion with a happy ending :-)
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=62463 After upgrading i get "Your site may not be secure." msg.] forum discussion

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

[[es:Actualización de moodle]]
[[fr:Mise à jour]]
[[nl:Upgraden]]
[[zh:升级]]

Upgrading

2007-04-01T09:47:02Z

Harrysmith: /* Using CVS */

Moodle is designed to upgrade cleanly from any earlier version to any later version. Please refer to [[Upgrading to Moodle 1.6]], [[Upgrading to Moodle 1.7]] or [[Upgrading to Moodle 1.8]] for particular considerations related to features of the version you are upgrading to.
__TOC__
When upgrading a Moodle installation you should follow these steps:

==Check the system requirements==
Spend some time re-reading the [[Installing Moodle | installation documentation]]. Check the system requirements for the version you are upgrading to in ''Administration > Server > [[Environment]]''.

== Backup important data ==

Although it is not strictly necessary, it is always a good idea to make a backup of any production system before a major upgrade, just in case you need to revert back to the older version for some reason. In fact, it's a good idea to automate your server to backup your Moodle installation daily, so that you can skip this step.

There are three areas that need backing up:

=== 1. The Moodle software directory itself ===

Make a separate copy of these files before the upgrade, so that you can retrieve your config.php and any modules you have added like themes, languages etc

=== 2. Your data directory ===

This is where uploaded content resides (such as course resources and student assignments) so it is very important to have a backup of these files anyway. Sometimes upgrades may move or rename directories within your data directory.

=== 3. Your database ===

Most Moodle upgrades will alter the database tables, adding or changing fields. Each database has different ways to backup. One way of backing up a MySQL database is to 'dump' it to a single SQL file. The following example shows Unix commands to dump the database called "moodle":

mysqldump -u username -p -C -Q -e -a moodle > moodle-backup-2007-04-01.sql

Substitute your database user account for username. The -p flag will prompt you for the password for the username specified by -u.

If your database host is different from the host you want to execute the backup command (usually the web server), you have to specify it with the -h option to mysqldump:

mysqldump -u username -p -h databasehost -C -Q -e -a moodle > moodle-backup-007-04-01.sql

You can also use the "Export" feature in Moodle's optional "MySQL Admin" web interface to do the same thing on all platforms. This interface can be downloaded from http://download.moodle.org/modules/integrations.php. It is an integration of PHPMyAdmin for the Moodle administration interface.

== Install the new Moodle software ==

=== Using a downloaded archive ===

Do not overwrite an old installation unless you know what you are doing ... sometimes old files can cause problems in new installations. The best way is to rename the current Moodle directory to something else, then unpack the new Moodle archive into the old location.

mv moodle moodle.backup
tar xvzf moodle-1.1.tgz

Next, copy across your config.php and any other plugins such as custom themes:

cp moodle.backup/config.php moodle
cp -pr moodle.backup/theme/mytheme moodle/theme/mytheme

=== Using CVS ===

You can use CVS for updating or upgrading your Moodle.
First you need to do a CVS checkout in your (empty) Moodle root directory.

'''For Linux servers'''

To do a CVS checkout of Moodle, you first have to logon to the Moodle CVS server.

<nowiki>cvs -d:pserver:anonymous@moodle.cvs.sourceforge.net:/cvsroot/moodle login</nowiki>
No password for anonymous, so just hit the Enter button.

Go to the directory where you want the Moodle root to come and type

<nowiki>cvs -z3 -d:pserver:anonymous@moodle.cvs.sourceforge.net:/cvsroot/moodle co -r MOODLE_18_STABLE moodle</nowiki>
(where MOODLE_18_STABLE is the desired version)

To update, just go into the Moodle root directory and update to the new files:

cvs update -dP
To update to a new version type in the following and change 18 to whatever newest version upgrade number is
cvs -Q update -dP -r MOODLE_18_STABLE

Make sure you use the "d" parameter to create new directories if necessary, and the "P" parameter to prune empty directories.

'''For Windows servers'''

You can use Tortoise CVS to do the initial checkout and the updates.

If you have been editing Moodle files, watch the messages very closely for possible conflicts. All your customised themes and non-standard plugins will be untouched.

Don't forget to visit the admin page after the CVS update proces has completed.

== Finishing the upgrade ==

The last step is to trigger the upgrade processes within Moodle.

To do this just visit the admin page of your installation e.g. ''<nowiki>http://example.com/moodle/admin</nowiki>''

It doesn't matter if you are logged in as admin or not. If you are upgrading from some older versions you would not be able to login before the upgrade anyway.

Moodle will automatically detect the new version and perform all the database or filesystem upgrades that are necessary. If there is anything it can't do itself (very rare) then you will see messages telling you what you need to do.

Assuming all goes well (no error messages) then you can start using your new version of Moodle and enjoy the new features!

==See also==

*Using Moodle [http://moodle.org/mod/forum/view.php?id=28 Installation problems] forum
*[[Upgrading to Moodle 1.6]]
*[[Installing Moodle]]
*[[Installation FAQ]]
*[http://otaru-jc.ac.jp/hagley/howtoupgrademoodlewithcpanel.swf How to upgrade Moodle with cpanel tutorial].
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=26731&parent=125858 Using cvs] forum discussion
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=56915 Upgrading from 1.5.2 to 1.7] forum discussion
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=56991 Upgrade nightmares.... any help appreciated] forum discussion with a happy ending :-)
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=62463 After upgrading i get "Your site may not be secure." msg.] forum discussion

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

[[es:Actualización de moodle]]
[[fr:Mise à jour]]
[[nl:Upgraden]]
[[zh:升级]]

Upgrading

2007-04-01T09:45:40Z

Harrysmith: /* 3. Your database */

Moodle is designed to upgrade cleanly from any earlier version to any later version. Please refer to [[Upgrading to Moodle 1.6]], [[Upgrading to Moodle 1.7]] or [[Upgrading to Moodle 1.8]] for particular considerations related to features of the version you are upgrading to.
__TOC__
When upgrading a Moodle installation you should follow these steps:

==Check the system requirements==
Spend some time re-reading the [[Installing Moodle | installation documentation]]. Check the system requirements for the version you are upgrading to in ''Administration > Server > [[Environment]]''.

== Backup important data ==

Although it is not strictly necessary, it is always a good idea to make a backup of any production system before a major upgrade, just in case you need to revert back to the older version for some reason. In fact, it's a good idea to automate your server to backup your Moodle installation daily, so that you can skip this step.

There are three areas that need backing up:

=== 1. The Moodle software directory itself ===

Make a separate copy of these files before the upgrade, so that you can retrieve your config.php and any modules you have added like themes, languages etc

=== 2. Your data directory ===

This is where uploaded content resides (such as course resources and student assignments) so it is very important to have a backup of these files anyway. Sometimes upgrades may move or rename directories within your data directory.

=== 3. Your database ===

Most Moodle upgrades will alter the database tables, adding or changing fields. Each database has different ways to backup. One way of backing up a MySQL database is to 'dump' it to a single SQL file. The following example shows Unix commands to dump the database called "moodle":

mysqldump -u username -p -C -Q -e -a moodle > moodle-backup-2007-04-01.sql

Substitute your database user account for username. The -p flag will prompt you for the password for the username specified by -u.

If your database host is different from the host you want to execute the backup command (usually the web server), you have to specify it with the -h option to mysqldump:

mysqldump -u username -p -h databasehost -C -Q -e -a moodle > moodle-backup-007-04-01.sql

You can also use the "Export" feature in Moodle's optional "MySQL Admin" web interface to do the same thing on all platforms. This interface can be downloaded from http://download.moodle.org/modules/integrations.php. It is an integration of PHPMyAdmin for the Moodle administration interface.

== Install the new Moodle software ==

=== Using a downloaded archive ===

Do not overwrite an old installation unless you know what you are doing ... sometimes old files can cause problems in new installations. The best way is to rename the current Moodle directory to something else, then unpack the new Moodle archive into the old location.

mv moodle moodle.backup
tar xvzf moodle-1.1.tgz

Next, copy across your config.php and any other plugins such as custom themes:

cp moodle.backup/config.php moodle
cp -pr moodle.backup/theme/mytheme moodle/theme/mytheme

=== Using CVS ===

You can use CVS for updating or upgrading your Moodle.
First you need to do a CVS checkout in your (empty) Moodle root directory.

'''For Linux servers'''

To do a CVS checkout of Moodle, you first have to logon to the Moodle CVS server.

<nowiki>cvs -d:pserver:anonymous@moodle.cvs.sourceforge.net:/cvsroot/moodle login</nowiki>
No password for anonymous, so just hit the Enter button.

Go to the directory where you want the Moodle root to come and type

<nowiki>cvs -z3 -d:pserver:anonymous@moodle.cvs.sourceforge.net:/cvsroot/moodle co -r MOODLE_15_STABLE moodle</nowiki>
(where MOODLE_15_STABLE is the desired version)

To update, just go into the Moodle root directory and update to the new files:

cvs update -dP
To update to a new version type in the following and change 17 to whatever newest version upgrade number is
cvs -Q update -dP -r MOODLE_17_STABLE

Make sure you use the "d" parameter to create new directories if necessary, and the "P" parameter to prune empty directories.

'''For Windows servers'''

You can use Tortoise CVS to do the initial checkout and the updates.

If you have been editing Moodle files, watch the messages very closely for possible conflicts. All your customised themes and non-standard plugins will be untouched.

Don't forget to visit the admin page after the CVS update proces has completed.

== Finishing the upgrade ==

The last step is to trigger the upgrade processes within Moodle.

To do this just visit the admin page of your installation e.g. ''<nowiki>http://example.com/moodle/admin</nowiki>''

It doesn't matter if you are logged in as admin or not. If you are upgrading from some older versions you would not be able to login before the upgrade anyway.

Moodle will automatically detect the new version and perform all the database or filesystem upgrades that are necessary. If there is anything it can't do itself (very rare) then you will see messages telling you what you need to do.

Assuming all goes well (no error messages) then you can start using your new version of Moodle and enjoy the new features!

==See also==

*Using Moodle [http://moodle.org/mod/forum/view.php?id=28 Installation problems] forum
*[[Upgrading to Moodle 1.6]]
*[[Installing Moodle]]
*[[Installation FAQ]]
*[http://otaru-jc.ac.jp/hagley/howtoupgrademoodlewithcpanel.swf How to upgrade Moodle with cpanel tutorial].
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=26731&parent=125858 Using cvs] forum discussion
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=56915 Upgrading from 1.5.2 to 1.7] forum discussion
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=56991 Upgrade nightmares.... any help appreciated] forum discussion with a happy ending :-)
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=62463 After upgrading i get "Your site may not be secure." msg.] forum discussion

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

[[es:Actualización de moodle]]
[[fr:Mise à jour]]
[[nl:Upgraden]]
[[zh:升级]]

Development:Roles

2006-06-08T17:12:01Z

Harrysmith: /* Admin - Catgory based */

'''Roles and capabilities''' are planned to be included in Moodle 1.7. For now, we have some basic ideas of how to implement such a structure in Moodle.

''Please note that none of the following is finalised.''

==Definitions==

By roles, we mean an identifier of the user's status, for example, teacher, student and forum moderator are examples of roles.

A capability is a permission to access some particular Moodle feature. Capabilities are associated with roles. For example, ''forum_canreadpost'' is a capability.

==The existing system==

Currently in Moodle, we have a fixed set of roles i.e. primary admin, admins, course creators, editing teachers, non-editing teachers, students, and guests. For each role, the capability or actions that they can performed are fixed. For example, the role student allows the user to submit an assignment, but doesn't allow the user to browse/edit other users' work. By using this setup we limit ourselves to a rather rigid set of capabilities for each role. If we want, say a particular student or group to be able to mark assignments in a particular course, we can't do that without giving these users teacher privileges.

==The new roles and capability system==

The new system will allow authorized users to define an arbitrary number of roles. Each role can have a customizable set of capabilities in every context. A context can be the whole Moodle site, a course, or a module instance, e.g. quiz 5 in 'Introduction to Photography'. An authorized user will be able to assign an arbitrary number of roles to each user. Since the capabilities in each role could be different, there could be conflict in capabilities. This is resolved by giving roles different 'priorities'. For example, to prevent a naughty student from posting, one could assign him a 'naughty student' role that does not allow him to post. This role should have a priority higher than that of a normal 'student' role.

To facilitate exceptional cases in roles and capabilities, we can use exception rules. For example, we can specify a rule saying that all students are able to mark/read other students' assignment in this particular course. Note that such rules need to have a priority as well. The capability of a user, in any context is then resolved by finding the highest priority role/rule.

''A smooth upgrade will be provided with 1.7. The existing roles (admin, teacher, student, etc), and the exisiting capabilities will be retained. This is done by creating default roles at site/course levels, and assigning the current users to these roles accordingly. The default roles will have default capabilities associated with them, which pretty much is what we have in 1.6. The whole process is automatic so there's nothing to worry about =). With no modifications, Moodle will operate exactly the same before and after the upgrade.''

==The plan==

There are a few major things that need to be done. Here's a list (in no particular order):

#Identify permissions required for site/course/each module.
#Define the database structure for storing roles and capabilities.
#Recode the whole of Moodle, including all modules to support the new structure. Instead of using <code>isteacher()</code> or <code>isstudent()</code> we should be using <code>has_capabity($capability, $instanceid)</code> etc. A new API for handling roles and capabilities will be implemented (accesslib.php).
#Add storage of capabilities for each module. Can be done either in a file, e.g. db/capability.xml, or as a sql file that gets installed to a central db whenever this module is installed. Either way, what do we do when we need to upgrade these capabilities? Some capabilities might needs refining/splitting later on. How do we control the 'version' of a capability?
#Consider interface issues, especially how to manage conflicting role/exception rules.
#Upon logging in, we should use a cache to store capability, down to module level. How should that be structured?
#Consider the impact on backup/restore.
#Upgrade path for current users. The user information in table user_coursecreators, user_admins, user_teachers, and user_students will most likely be migrated to the new roles and capabilities tables. The users will most likely be assigned default roles that comes with default capabilities (e.g. teachers, admins, students, etc). The old tables themselves could possibly be dropped at the end of the upgrade.

==Capabilities==

This is a comprehensive list of capabilities, well, in the making. Please edit. Should we distinguish canedit and candelete?

What about a canview capability? Like for choice, where a person is allowed to see the choice question but not participate in it? --[[User:N Hansen|N Hansen]] 19:29, 16 May 2006 (WST)

Certainly need a canview or cansee capability for parents as linked to their childs data/contributions.

Do we need to add canview and cansearch logs at site/course/user/group level?

===Site-level Capabilities===

#canconfigsitevariables - applcialbe in admin/config.php
#canreadblogs
#canpostblogs
#candeleteallblogs
#canbrowseuser
#canviewhiddenactivity
#cancreatecourse
#caneditownprofile
#caneditallprofiles

===Course-level Capabilities===

#viewcoursecontent
#caneditcourse
#cancreatebackups
#canrestorebackups
#cancreateblocks
#caneditblocks
#candeleteblocks

===Module-level Capabilities===

#Assignment
##assignment_canadd
##assignment_canedit
##assignment_candelete
##assignment_cansubmit
##assignment_mark - marking, viewing of list of submitted assignments
##assignment_canviewsubmissions
#Chat
##chat_canadd
##chat_canedit
##chat_candelete
##chat_canparticipate
##chat_canviewpastsessions
#Choice
##choice_canadd
##choice_canedit
##choice_candelete
##choice_canparticipate
##choice_canviewresponses
#Database
##database_canadd
##database_canedit
##databaes_candelete
##database_canaddentry
##database_canaddtemplates
##database_canedittemplates
##database_candeleteownentry
##database_candeleteallentry
##database_cancomment
##database_candeletecomment
##database_canrate
#Exercise
##exercise_canadd
##exercise_canedit
##exercise_candelete
##exercise_canassess
#Forum
##forum_canadd
##forum_canedit
##forum_candelete
##forum_canreadpost
##forum_canstartnewdiscussion
##forum_canreply
##forum_caneditallpost
##forum_candeleteallpost
##forum_canrate
#Glossary
##glossary_canadd
##glossary_canedit
##glossary_candelete
##glossary_canaddcat
##glossary_caneditcat
##glossary_candeletecat
##glossary_canadditem
##glossary_candeleteitem
##glossary_canedititem
##glossary_cancomment
##glossary_canimportentries
##glossary_canexportentries
##glossary_canapprove
#Hotpot
##hotpot_candd
##hotpot_canedit
##hotpot_candelete
##hotpot_canparticipate
#Label
##label_canadd
##label_canedit
##label_candelete
#Lams
##lams_canadd
##lams_canedit
##lams_candelete
#Lesson
##lesson_canadd
##lesson_canedit
##lesson_candelete
##lesson_canparticipate
#Quiz
##quiz_canadd
##quiz_canedit
##quiz_candelete
##quiz_canaddquestion
##quiz_caneditquestion
##quiz_candeletequestion
##quiz_canparticipate
##quiz_cangrade
#Resource
##resource_canadd
##resource_canedit
##resource_candelete
#Scorm
##scorm_canadd
##scorm_canedit
##socrm_candelete
#Survey
##survey_canadd
##survey_canedit
##survey_candelete
##survey_canviewresponses
#Wiki
##wiki_canadd
##wiki_canedit
##wiki_candelete
##wiki_canstartnewwiki
##wiki_canparticipate
#Workshop
##workshop_canadd
##workshop_canedit
##workshop_candelete
##workshop_cangrade
##workshop_canparticipate

==Scenarios==

This section is for brainstorming some example roles that we would like to support:

===Student===
Has this one been missed?

===Site Designers===
Is there a role for peole involved in how the site looks but not full administrators? Thinking here of online control of themes rather than FTP theme uploading. But in either case they caneditlogos, caneditcss, candeditlevelatwhichthemeapplies.

===Educational Authority Adviser===
Someone who would want to browse the site and may be asked to comment or contribute to particular discussions or developments in school. Access for this role would be controlled by the school in the case of school level moodles but may be different if there were to be a Local Authority wide Moodle.

===Educational Inspector===
Someone who will visit the site to verify the school's self review that comments on home school relationships, extending the classroom etc. They may want to see summaries of usage and reports from surveys garnering parent and pupil views.

===Second Marker / Moderator===
A teacher within ths site that has access to assignments and quizzes from another teacher's course for second marking purposes. This may need additional functionality adding to the assignment module so that two sets of grades/feedback can be given to one set of assignments.

===External Examiner===
Has all the rights of inpectors, but would also need to be able to review assignments and feedback, view forums, glossaries etc. However, would not want to post, feedback onto the site at all.

===Parent===
A parent will have one or more children in one or more institutions which could be using one or more moodle instances or a mixture of Learning Platforms. A parent's role will vary depending on the age of their children and whether they are contributing as a parent or a school supporter.

In Early Years (EY) and Key Stage 1 (KS1) they may play/learn on an activity or write for the child. Parents often interpret homework tasks and read to their children perhaps filling in a joint reading diary.

In Key stages 3 and 4 this changes to more of a monitoring/awareness role where a parent would expect to have a summary report of attendance, attainment and general achievement on a weekly/monthly/termly or annual basis. Parents will often be asked to sign and write back comments about this review report.

In all Key Stages there is a great need for parents to receive communication from the school which they can confirm they have received by signing a form. In some cases this may also involve making choices from a list. It may also involve payment for a trip or disco being returned so there could be the possibility of electronic payments.

Parent's evening often involve complex booking systems that attempt to get parent's and teachers together. Easy for EY/KS1/KS2 very difficult for KS3/KS4. Wow would this help if it was built into the Learning Platform.

In some cases there needs to be confidential communication between the parent and the teacher without the child being party to this. It may involve teaching and learning but could also involve a behaviour or medical issue. Often this may be done via a sealed letter or face to face.

The latest incarnation of OfSTED with the Self Review Framework (SEF) there is a greater emphasis on schools gathering parent voice via surveys and discussion. There is a clear match here with parents have access to parental votes, questionnaires and discussions and for schools to be able to publish news, results and reports back to parents.

In the UK the LP framework and agenda as being pushed by the DfES via Becta emphasises that within the mandatory groups and roles functionality the parent role is likely to be required to meet the LP Framework procurement standard.

===Manager===
''Please add text here...''

===Weekly Seminar Leader===
''In a university seminar, typically 8-15 students in their 3rd/4th year, each student is responsible for leading one topic in a study series. I ask each student to research 5-10 resources, then give a powerpoint presentation to the other students. This is followed by an in-class discussion and then online homework. The homework involves some fun quiz questions and then some reflective journal questions. I ask each seminar leader to prepare the quiz questions and journal questions as well as their presentation. To do that, I would like to assign activity-making/authoring roles to the student--either for a short period, or for duration of the whole course. Thus "Allow Quiz Authoring Role" or "Allow Assignment Authoring Role" at the course level or, if possible, even the Topic level (in a topic or week format course) would be important.''

===Mentor/Mentee===
''Please add text here...''

===Community-Designed Rating Criteria===
''The gradebook tends to be the domain of the teacher. What if community/peer ratings/marks could also be entered there? What if peer assessment criteria could be designed by the students, not just the teacher?''

===Visitor===

This would be a role whereby one could allow a visitor to visit one's classroom. This might be a colleague interested in seeing your course, or a journalist who might be writing an article about one's site. They should not be able to see the names of any students anywhere (eg recent activity, forum posts) for privacy reasons. They should be able to try out things like quizzes, and lessons but no grades would be recorded (like in teacher preview mode). They would not be able to participate in choices and forums but could view them. It would be read only in a way like former-student role below but without access to a particular student's records that former student role would grant.

===Former Student===
This role would be of particular use for courses with rolling enrollments. This role would be one where a student had completed all of the requirements of a course (ie assignments, quizzes etc.) but wished to have continued access to the course material for review or consultation. The key factor is that one would give access to the completed student to the notes he read, his work and the teacher's comments on it, but he would not be allowed to do anything that would take up the teacher's time. In other words, a sort-of read-only access to the course. How forums, which might contain pertinent information and would continue to grow, would be handled is a question. Perhaps the student would be shown only what was in the forums at the time he completed the course. He would not be allowed to see any new posts or add any himself. Same thing for database and glossary entries. In other words, a snapshot of the course at the time his regular enrollment ended. He shouldn't be able to see the names or profiles of any newly enrolled students for privacy reasons-hence the restrictions on forum access. One issue that would have to be dealt with would be changes to existing modules-such as resources. Does the student get access to the module as it was or as it is? We have no versioning of resources in Moodle so this would be a problem. What about a teacher changing a quiz question so that the answer is different? What would a former student see?

===Librarian===

Reference Librarians have an active role in most of the courses taught at Earlham College (with Bibliographic Instruction). The Librarian role within Moodle could encompass default read access to all courses (unless prohibited by course teacher) and read access to all components of the course unless access is barred (again by teacher). The Librarians would also perhaps have a block called perhaps Reference Services or Reference Desk with write access where they could deposit resources. Also this block might have a chat applet whereby enrolled students could chat to the Reference Librarian on duty about their bibliographic research needs.

===Teacher===

Teachers should have read access to other Teacher's courses unless explictly prohibited. They should be able to set parts of their own course to be totally private (perhaps even to admin?). Just as each activity can currently be set to have group access, each activity could have a permissions field. Teachers could set default permissions for all activities on their course (eg they might disallow Librarian access for example) and then change the access permission for an individual activity.

I think that what is needed is a simple heirarchy of permissions and levels of granularity.

===Community Education Tutors/Trainers===
Teachers may be community adult education trainers making use of a school moodle so must only have access to their courses unless given access elsewhere. They would not necessarily get the default teacher privileges.

===Secretary/Student Worker===

We often have faculty who want their departmental secretary or student worker to scan and upload files and perhaps create resources. Currently they have to be given teacher access to the course. This is dangerous from a FERPA standpoint since they could easily get access to grades.

===Teaching Assistant===

Our Faculty frequently have undergraduate students acting as Teaching Assistants. These students need to be able to add resources, create assignments, and possibly grade assignments. However, due to FERPA they cannot have access to other students' overall grade information. I think the requirements here are slightly different than those of Secretary/Student Worker

===Admin - Catgory based===

Basically a person in between full Admin and Creator that has the permissions of an Admin but only with respect to courses and students. Currently a Creator has permissions site-wide which does not always meet the requirements of a given organisation (e.g. Department A may not be happy that a person from Department B can create/modify courses within Department A's area). The ability to designate a Creator within a specific category would allow areas to be set up for a faculty/department/organisation and allow the Admin for that area to create/delete courses, upload users, add site-wide entries to the calendar etc.

==See also==

*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=38788 Roles and Permissions architecture] forum discussion

[[Category:Developer]]
[[Category:Future]]

Development:Roles

2006-06-08T17:11:15Z

Harrysmith: /* Teaching Assistant */

'''Roles and capabilities''' are planned to be included in Moodle 1.7. For now, we have some basic ideas of how to implement such a structure in Moodle.

''Please note that none of the following is finalised.''

==Definitions==

By roles, we mean an identifier of the user's status, for example, teacher, student and forum moderator are examples of roles.

A capability is a permission to access some particular Moodle feature. Capabilities are associated with roles. For example, ''forum_canreadpost'' is a capability.

==The existing system==

Currently in Moodle, we have a fixed set of roles i.e. primary admin, admins, course creators, editing teachers, non-editing teachers, students, and guests. For each role, the capability or actions that they can performed are fixed. For example, the role student allows the user to submit an assignment, but doesn't allow the user to browse/edit other users' work. By using this setup we limit ourselves to a rather rigid set of capabilities for each role. If we want, say a particular student or group to be able to mark assignments in a particular course, we can't do that without giving these users teacher privileges.

==The new roles and capability system==

The new system will allow authorized users to define an arbitrary number of roles. Each role can have a customizable set of capabilities in every context. A context can be the whole Moodle site, a course, or a module instance, e.g. quiz 5 in 'Introduction to Photography'. An authorized user will be able to assign an arbitrary number of roles to each user. Since the capabilities in each role could be different, there could be conflict in capabilities. This is resolved by giving roles different 'priorities'. For example, to prevent a naughty student from posting, one could assign him a 'naughty student' role that does not allow him to post. This role should have a priority higher than that of a normal 'student' role.

To facilitate exceptional cases in roles and capabilities, we can use exception rules. For example, we can specify a rule saying that all students are able to mark/read other students' assignment in this particular course. Note that such rules need to have a priority as well. The capability of a user, in any context is then resolved by finding the highest priority role/rule.

''A smooth upgrade will be provided with 1.7. The existing roles (admin, teacher, student, etc), and the exisiting capabilities will be retained. This is done by creating default roles at site/course levels, and assigning the current users to these roles accordingly. The default roles will have default capabilities associated with them, which pretty much is what we have in 1.6. The whole process is automatic so there's nothing to worry about =). With no modifications, Moodle will operate exactly the same before and after the upgrade.''

==The plan==

There are a few major things that need to be done. Here's a list (in no particular order):

#Identify permissions required for site/course/each module.
#Define the database structure for storing roles and capabilities.
#Recode the whole of Moodle, including all modules to support the new structure. Instead of using <code>isteacher()</code> or <code>isstudent()</code> we should be using <code>has_capabity($capability, $instanceid)</code> etc. A new API for handling roles and capabilities will be implemented (accesslib.php).
#Add storage of capabilities for each module. Can be done either in a file, e.g. db/capability.xml, or as a sql file that gets installed to a central db whenever this module is installed. Either way, what do we do when we need to upgrade these capabilities? Some capabilities might needs refining/splitting later on. How do we control the 'version' of a capability?
#Consider interface issues, especially how to manage conflicting role/exception rules.
#Upon logging in, we should use a cache to store capability, down to module level. How should that be structured?
#Consider the impact on backup/restore.
#Upgrade path for current users. The user information in table user_coursecreators, user_admins, user_teachers, and user_students will most likely be migrated to the new roles and capabilities tables. The users will most likely be assigned default roles that comes with default capabilities (e.g. teachers, admins, students, etc). The old tables themselves could possibly be dropped at the end of the upgrade.

==Capabilities==

This is a comprehensive list of capabilities, well, in the making. Please edit. Should we distinguish canedit and candelete?

What about a canview capability? Like for choice, where a person is allowed to see the choice question but not participate in it? --[[User:N Hansen|N Hansen]] 19:29, 16 May 2006 (WST)

Certainly need a canview or cansee capability for parents as linked to their childs data/contributions.

Do we need to add canview and cansearch logs at site/course/user/group level?

===Site-level Capabilities===

#canconfigsitevariables - applcialbe in admin/config.php
#canreadblogs
#canpostblogs
#candeleteallblogs
#canbrowseuser
#canviewhiddenactivity
#cancreatecourse
#caneditownprofile
#caneditallprofiles

===Course-level Capabilities===

#viewcoursecontent
#caneditcourse
#cancreatebackups
#canrestorebackups
#cancreateblocks
#caneditblocks
#candeleteblocks

===Module-level Capabilities===

#Assignment
##assignment_canadd
##assignment_canedit
##assignment_candelete
##assignment_cansubmit
##assignment_mark - marking, viewing of list of submitted assignments
##assignment_canviewsubmissions
#Chat
##chat_canadd
##chat_canedit
##chat_candelete
##chat_canparticipate
##chat_canviewpastsessions
#Choice
##choice_canadd
##choice_canedit
##choice_candelete
##choice_canparticipate
##choice_canviewresponses
#Database
##database_canadd
##database_canedit
##databaes_candelete
##database_canaddentry
##database_canaddtemplates
##database_canedittemplates
##database_candeleteownentry
##database_candeleteallentry
##database_cancomment
##database_candeletecomment
##database_canrate
#Exercise
##exercise_canadd
##exercise_canedit
##exercise_candelete
##exercise_canassess
#Forum
##forum_canadd
##forum_canedit
##forum_candelete
##forum_canreadpost
##forum_canstartnewdiscussion
##forum_canreply
##forum_caneditallpost
##forum_candeleteallpost
##forum_canrate
#Glossary
##glossary_canadd
##glossary_canedit
##glossary_candelete
##glossary_canaddcat
##glossary_caneditcat
##glossary_candeletecat
##glossary_canadditem
##glossary_candeleteitem
##glossary_canedititem
##glossary_cancomment
##glossary_canimportentries
##glossary_canexportentries
##glossary_canapprove
#Hotpot
##hotpot_candd
##hotpot_canedit
##hotpot_candelete
##hotpot_canparticipate
#Label
##label_canadd
##label_canedit
##label_candelete
#Lams
##lams_canadd
##lams_canedit
##lams_candelete
#Lesson
##lesson_canadd
##lesson_canedit
##lesson_candelete
##lesson_canparticipate
#Quiz
##quiz_canadd
##quiz_canedit
##quiz_candelete
##quiz_canaddquestion
##quiz_caneditquestion
##quiz_candeletequestion
##quiz_canparticipate
##quiz_cangrade
#Resource
##resource_canadd
##resource_canedit
##resource_candelete
#Scorm
##scorm_canadd
##scorm_canedit
##socrm_candelete
#Survey
##survey_canadd
##survey_canedit
##survey_candelete
##survey_canviewresponses
#Wiki
##wiki_canadd
##wiki_canedit
##wiki_candelete
##wiki_canstartnewwiki
##wiki_canparticipate
#Workshop
##workshop_canadd
##workshop_canedit
##workshop_candelete
##workshop_cangrade
##workshop_canparticipate

==Scenarios==

This section is for brainstorming some example roles that we would like to support:

===Student===
Has this one been missed?

===Site Designers===
Is there a role for peole involved in how the site looks but not full administrators? Thinking here of online control of themes rather than FTP theme uploading. But in either case they caneditlogos, caneditcss, candeditlevelatwhichthemeapplies.

===Educational Authority Adviser===
Someone who would want to browse the site and may be asked to comment or contribute to particular discussions or developments in school. Access for this role would be controlled by the school in the case of school level moodles but may be different if there were to be a Local Authority wide Moodle.

===Educational Inspector===
Someone who will visit the site to verify the school's self review that comments on home school relationships, extending the classroom etc. They may want to see summaries of usage and reports from surveys garnering parent and pupil views.

===Second Marker / Moderator===
A teacher within ths site that has access to assignments and quizzes from another teacher's course for second marking purposes. This may need additional functionality adding to the assignment module so that two sets of grades/feedback can be given to one set of assignments.

===External Examiner===
Has all the rights of inpectors, but would also need to be able to review assignments and feedback, view forums, glossaries etc. However, would not want to post, feedback onto the site at all.

===Parent===
A parent will have one or more children in one or more institutions which could be using one or more moodle instances or a mixture of Learning Platforms. A parent's role will vary depending on the age of their children and whether they are contributing as a parent or a school supporter.

In Early Years (EY) and Key Stage 1 (KS1) they may play/learn on an activity or write for the child. Parents often interpret homework tasks and read to their children perhaps filling in a joint reading diary.

In Key stages 3 and 4 this changes to more of a monitoring/awareness role where a parent would expect to have a summary report of attendance, attainment and general achievement on a weekly/monthly/termly or annual basis. Parents will often be asked to sign and write back comments about this review report.

In all Key Stages there is a great need for parents to receive communication from the school which they can confirm they have received by signing a form. In some cases this may also involve making choices from a list. It may also involve payment for a trip or disco being returned so there could be the possibility of electronic payments.

Parent's evening often involve complex booking systems that attempt to get parent's and teachers together. Easy for EY/KS1/KS2 very difficult for KS3/KS4. Wow would this help if it was built into the Learning Platform.

In some cases there needs to be confidential communication between the parent and the teacher without the child being party to this. It may involve teaching and learning but could also involve a behaviour or medical issue. Often this may be done via a sealed letter or face to face.

The latest incarnation of OfSTED with the Self Review Framework (SEF) there is a greater emphasis on schools gathering parent voice via surveys and discussion. There is a clear match here with parents have access to parental votes, questionnaires and discussions and for schools to be able to publish news, results and reports back to parents.

In the UK the LP framework and agenda as being pushed by the DfES via Becta emphasises that within the mandatory groups and roles functionality the parent role is likely to be required to meet the LP Framework procurement standard.

===Manager===
''Please add text here...''

===Weekly Seminar Leader===
''In a university seminar, typically 8-15 students in their 3rd/4th year, each student is responsible for leading one topic in a study series. I ask each student to research 5-10 resources, then give a powerpoint presentation to the other students. This is followed by an in-class discussion and then online homework. The homework involves some fun quiz questions and then some reflective journal questions. I ask each seminar leader to prepare the quiz questions and journal questions as well as their presentation. To do that, I would like to assign activity-making/authoring roles to the student--either for a short period, or for duration of the whole course. Thus "Allow Quiz Authoring Role" or "Allow Assignment Authoring Role" at the course level or, if possible, even the Topic level (in a topic or week format course) would be important.''

===Mentor/Mentee===
''Please add text here...''

===Community-Designed Rating Criteria===
''The gradebook tends to be the domain of the teacher. What if community/peer ratings/marks could also be entered there? What if peer assessment criteria could be designed by the students, not just the teacher?''

===Visitor===

This would be a role whereby one could allow a visitor to visit one's classroom. This might be a colleague interested in seeing your course, or a journalist who might be writing an article about one's site. They should not be able to see the names of any students anywhere (eg recent activity, forum posts) for privacy reasons. They should be able to try out things like quizzes, and lessons but no grades would be recorded (like in teacher preview mode). They would not be able to participate in choices and forums but could view them. It would be read only in a way like former-student role below but without access to a particular student's records that former student role would grant.

===Former Student===
This role would be of particular use for courses with rolling enrollments. This role would be one where a student had completed all of the requirements of a course (ie assignments, quizzes etc.) but wished to have continued access to the course material for review or consultation. The key factor is that one would give access to the completed student to the notes he read, his work and the teacher's comments on it, but he would not be allowed to do anything that would take up the teacher's time. In other words, a sort-of read-only access to the course. How forums, which might contain pertinent information and would continue to grow, would be handled is a question. Perhaps the student would be shown only what was in the forums at the time he completed the course. He would not be allowed to see any new posts or add any himself. Same thing for database and glossary entries. In other words, a snapshot of the course at the time his regular enrollment ended. He shouldn't be able to see the names or profiles of any newly enrolled students for privacy reasons-hence the restrictions on forum access. One issue that would have to be dealt with would be changes to existing modules-such as resources. Does the student get access to the module as it was or as it is? We have no versioning of resources in Moodle so this would be a problem. What about a teacher changing a quiz question so that the answer is different? What would a former student see?

===Librarian===

Reference Librarians have an active role in most of the courses taught at Earlham College (with Bibliographic Instruction). The Librarian role within Moodle could encompass default read access to all courses (unless prohibited by course teacher) and read access to all components of the course unless access is barred (again by teacher). The Librarians would also perhaps have a block called perhaps Reference Services or Reference Desk with write access where they could deposit resources. Also this block might have a chat applet whereby enrolled students could chat to the Reference Librarian on duty about their bibliographic research needs.

===Teacher===

Teachers should have read access to other Teacher's courses unless explictly prohibited. They should be able to set parts of their own course to be totally private (perhaps even to admin?). Just as each activity can currently be set to have group access, each activity could have a permissions field. Teachers could set default permissions for all activities on their course (eg they might disallow Librarian access for example) and then change the access permission for an individual activity.

I think that what is needed is a simple heirarchy of permissions and levels of granularity.

===Community Education Tutors/Trainers===
Teachers may be community adult education trainers making use of a school moodle so must only have access to their courses unless given access elsewhere. They would not necessarily get the default teacher privileges.

===Secretary/Student Worker===

We often have faculty who want their departmental secretary or student worker to scan and upload files and perhaps create resources. Currently they have to be given teacher access to the course. This is dangerous from a FERPA standpoint since they could easily get access to grades.

===Teaching Assistant===

Our Faculty frequently have undergraduate students acting as Teaching Assistants. These students need to be able to add resources, create assignments, and possibly grade assignments. However, due to FERPA they cannot have access to other students' overall grade information. I think the requirements here are slightly different than those of Secretary/Student Worker

===Admin - Catgory based===

Basically a person in between full Admin and Creator that has the permissions of an Admin but only with respect to courses and students. Currently a Creator has permissions site-wide which does not always meet the requirements of a given organisation (e.g. Department A may not be happy that a person from Department B can create/modify courses within Department A's area). The ability to designate a Creator within a specific category would allow areas to be set up for a faculty/department/organisation and allow the Admin for that area to create/delete courses, upload users, add sitewide entries to the calendar etc.

==See also==

*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=38788 Roles and Permissions architecture] forum discussion

[[Category:Developer]]
[[Category:Future]]

Adding a new course

2006-03-18T13:10:11Z

Harrysmith: /* Delete a course */

Course sub-categories may be created by adding a new course category then using the "move category to" drop-down menu to move the category inside another category.

Similarly, sub-sub-categories etc. may be created.

===Add a course===
1. log in as an admin
2. click on ''Courses'' in the admin menu
3. navigate into the category where you want to add the course
4. click on the ''Add a new course'' button
5. set up your new course

[[image:Admin_menu.jpg|frame|left| log in as admin and click on ''Courses'']]
 
[[image:ADDACOURSE.GIF|frame|left|click on the ''Add a new course'' button to add a course]]
 
[[image:Setupcourse.gif|frame|left|set up your new course]]
 

===Delete a course ===
To delete a course

1. log in as an admin
2. click on ''Courses'' in the admin menu
3. turn on editing
4. click on the x to delete the course

[[image:Admin_menu.jpg|frame|left| log in as admin and click on ''Courses'']]
 
[[image:Courses.jpg|frame|left|click on the x to delete the course]]
 

===Add a teacher===

To add a teacher

1. log in as an admin or a teacher

2. click on ''Teachers'' in the Admin Menu (in screen capture below called ''Administrators'')

3. search for a teacher

4. click on the ''Add teacher'' link

[[image:Addadmin1.gif|frame|left|the ''Teachers'' link in this screen capture has been renamed ''Administrators'']]
 

[[image:Addadmin2.gif|frame|left|search for a teacher to add (must already have an account, of course)]]
 

[[image:Addadmin3.gif|frame|left|click on the ''Add teacher'' link]]
 

[[Category: Administrator]]