MoodleDocs - Contribucions de l'usuari [ca]

Discussió:Category enrolments

2013-01-09T06:06:33Z

Poltawski: Created page with "I desperately tried to make this page more understandable because having just tried to use this plugin I was perplexed by how to use it. I'm afraid I couldn't think of a way of s..."

I desperately tried to make this page more understandable because having just tried to use this plugin I was perplexed by how to use it. I'm afraid I couldn't think of a way of succinctly explaining it. I do know how this plugin works now though, so if anyone would like to know how it works (and improve the documentation) please feel free to ask me. --[[User:Dan Poltawski|Dan Poltawski]] 14:06, 9 January 2013 (WST)

Category enrolments

2013-01-09T06:04:11Z

Poltawski:

{{Enrolment}}

The category enrolments plugin allows users to be enrolled in a category as opposed to individual courses. The plugin has to be enabled by the site administrator (see [[Enrolment plugins]]). The category enrolment plugin will synchronise any role assignments at category context with 'enrol/category:synchronised' permission set to allow.

Note: It is recommended that [[Cohort sync]] is used in preference to category enrolments. There are performance issues with category enrolments. See http://tracker.moodle.org/browse/MDL-23840.

==Settings for category enrolment==

*Go to the category into which you wish to enrol users. '''Note:''' You need to have category rights (manager or administrator)

*In the ''Settings'' box,click ''Assign roles''. The list of possible roles you can assign will appear:
[[File:Categoryassign.png]]

== Admin settings for category enrolment==

The category enrolment plugin may be enabled or disabled throughout the site in ''Settings > Site administration > Plugins > Enrolments> Manage enrol plugins.''

===Assigning teachers or students to a category===

*By default, only managers and course creators can be assigned category-wide. If you want to add teachers or students then the site administrator needs to tick the "category" box in their role in ''Settings > Site administration > Users > Permissions > Define roles''.
*To ensure they will be automatically assigned as teachers/students in any new courses you make, the administrator needs to set to "allow" the capability ''enrol/category:synchronised'' for the role in question in ''Settings > Site Administration > Users > Permissions > Define roles''

[[File:Enrolcategorysync.png]]

[[ja:カテゴリ登録]]
[[de:Kursbereichseinschreibung]]

error/moodle/invalidrecord

2012-12-14T07:52:38Z

Poltawski:

This error was probably caused by a record not existing in the database

[[Category:Error|Invalidrecord]]

Caching

2012-12-13T04:34:27Z

Poltawski: Very basic overview of the cache settings. This is not great. I've filled MDL-37145 to improve this further.

{{Performance}}{{New features}}

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

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

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

==General approach to performance testing==

Here is the general strategy you should be taking:

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

==How to use the caching settings==

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

=== Types of cache ===

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

===Installed cache stores===

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

===Configured store instances===

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

===Known cache definitions===

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

==Stores used when no mapping is present==

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

==Other performance testing==

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

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

==See also==

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

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

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

SSL certificate for moodle.org

2012-12-04T15:24:28Z

Poltawski: added rhel note, as I think the package name is the same

== Synopsis ==

Your site may communicate with moodle.org sites - for example when it [[Notifications|checks for available updates]] or when it [[Automatic updates deployment|installs an update]]. This communication is done via the secure HTTPS protocol. Your site validates the SSL certificate of the moodle.org site (such as the [https://moodle.org/plugins Moodle plugins directory]) and verifies its identity. To pass this verification, there must be a certificate (in the PEM format) of the [http://en.wikipedia.org/wiki/Certificate_authority certificate authority (CA)] that issued the certificate for moodle.org installed at your server.

The SSL certificate of moodle.org sites has been issued by the [https://www.digicert.com/digicert-root-certificates.htm DigiCert CA] and signed by their ''DigiCert High Assurance EV Root CA'' certificate.

== Problem ==

If this CA certificate is missing, the remote site (moodle.org) can not be verified and your Moodle refuses to fetch the data (to protect you against so called man-in-the-middle attack). The exact location of that certificate at your server depends on the OS type and other settings. At Linux servers it may be typically found at ''/usr/share/ca-certificates/mozilla/DigiCert_High_Assurance_EV_Root_CA.crt'' for example.

Missing CA certificate causes error when checking for available updates and attempting to install them.

== Solutions ==

=== Update your operating system (recommended) ===

The recommended way to fix this problem is to update your server's operating system so that it contains recent SSL certificates of common certificate authorities. At Debian and RedHat based distributions, these certificates are distributed in the ''ca-certificates'' package. Gentoo servers provide them via the ''app-misc/ca-certificates'' ebuild. It's also a good idea to make sure that the OpenSSL libraries (libssl) and cURL libraries (libcurl) are up-to-date at your server.

=== Provide the CA certificate manually ===

If updating the operating system is not an option for you and the administrator of the server refuses to update the CA certificates at the server (there's not a good argument for that though), here is a workaround for you. You can download the [https://www.digicert.com/testroot/DigiCertHighAssuranceEVRootCA.crt DigiCert High Assurance EV Root CA] certificate from [https://www.digicert.com/digicert-root-certificates.htm digicert.com] and put it into your ''moodledata/moodleorgca.crt'' file. If the certificate is found there, Moodle will use it instead of relying on the one provided by the operating system.

It must be highlighted that you really should get the CA certificate to your server's operating system as described above. The solution based on moodleorgca.crt should be considered as a temporary only.

Forum discussion subscription plugin

2012-09-04T01:20:58Z

Poltawski: remove duplicate link

== Description ==

Local plugin for allowing email subscription to discussions (threads) and not the whole forum.

Discussion subscription can works together with full forum subscription, but the user will receive the same emails two times.

Discussion subscription supports also diggest if the user has enabled this option in his profile.

== Configuration ==

As a teacher, in the forum activity go to the settings block and click on "Discussion subscriptions" -> "Enable"

Once enabled, the users will be able to click on the "Subscribe to this discussion" in a discussion page.

== Credits ==

Juan Leyva <http://twitter.com/#!/jleyvadelgado>

http://moodle.org/user/profile.php?id=49568

== See also ==

http://moodle.org/plugins/view.php?plugin=local_dsubscription

https://github.com/jleyva/moodle-local_dsubscription

[[Category: Contributed code]]

Database transfer

2012-07-31T07:25:16Z

Poltawski:

{{Managing a Moodle site}}
The database transfer tool in Moodle 2.3.2 onwards enables an administrator to migrate their Moodle site from one database to another, for example from MySQL to Postgres.

The tool is currently classed as an experimental feature and may be found in ''Settings > Site administration > Development > Experimental > Database migration''. There is also a command line script in 'admin/tool/dbtransfer/cli/migrate.php'.

The dbtransfer tool uses the XMLDB schema definitions from Moodle and installed plugins to retrieve the data from one database and transfer it another.

==See also==

* MDL-34441 finish dbtransfer tool implementation

Using Moodle forum discussions:
* [http://moodle.org/mod/forum/discuss.php?d=207413 Moving Moodle from Oracle to PostgreSQL (dbtransfer tool)]
* [http://moodle.org/mod/forum/discuss.php?d=206759 Where did dbtransfer.php go?]

{{stub}}

Database transfer

2012-07-31T07:25:05Z

Poltawski: added some additional basic details

Database transfer

2012-07-31T07:18:48Z

Poltawski: i've removed the new feature in 2.3 flag, because its been there since 2.0, in various states.

Skydrive repository

2012-06-28T16:10:08Z

Poltawski: Created page with "The Microsoft Skydrive repository allows you to access your documents from Microsoft Skydrive within Moodle. ==Installation== You must register your Moodle with Microsoft in or..."

The Microsoft Skydrive repository allows you to access your documents from Microsoft Skydrive within Moodle.

==Installation==
You must register your Moodle with Microsoft in order to allow Moodle to communicate with Microsoft. You must register your application via the following steps:

# Visit the Microsoft developer centre: [https://manage.dev.live.com/Applications/Index https://manage.dev.live.com/Applications/Index]
# Choose ‘Create an Application’ and Fill out the form with a name for your Moodle.
# Submit the form by clicking ‘I Accept’
# On the next page you must visit the link ‘Application Settings Page’.
# You will be shown the basic settings page, Click ‘API Setttings’ on the left.
# You will be shown ‘client ID’ and ‘client secret’, these need to be stored in Moodle.
# Important: As part of the registration process, you will need to enter the url from the skydrive settings page in the 'redirect domain' section.

[[Category:Contributed code]]

Usuari:Dan Poltawski

2012-06-28T14:29:49Z

Poltawski:

Please see my [http://moodle.org/user/view.php?id=104159&course=5 Moodle.org Profile] as I don't keep this one up to date.. (only just keep the other one up date :))

Upload users

2012-06-20T03:07:13Z

Poltawski: remove AJAX and Javascript MDL-32908

{{Accounts}}
An administrator can upload multiple user accounts via text file in ''Settings > Site administration > Users > Accounts > Upload users''.

There are many robust options for uploading information (fields associated with a user) with this method: from enrolling users in multiple courses with course specific [[Roles|roles]] to updating user information in the [[User profile]] to deleting users from the site.

{{New features}}Rather than uploading the text file, it can simply dragged from the desktop and dropped into the upload area, as demonstrated in the screencast [http://youtu.be/6E-TQXTkZB0 Drag and drop new users into Moodle 2.3] (by Mary Cooch).

''Tip:'' It is usually not necessary to upload users in bulk with Upload users. To keep maintenance work down you should first explore forms of authentication that do not require manual maintenance, such as [[External database authentication|connecting to existing external databases]] or letting the users create their own accounts ([[Self enrolment]]). See [[Authentication]] for more information.

[[File:Upload users initial 2.0.JPG|thumb|center|Initial upload users screen 2.1]]

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

# Create file for uploading
# Go to ''Settings > Site administration > Users > Accounts > Upload users''
# Add file to upload
# Upload users preview - check settings and default user profile settings
# Upload users preview - click "Upload users"
# Upload users results - shows list of users, exceptions made in upload and summary of number of users
# Upload users results - click "Continue"
# Returns to Upload users screen

==Updating users preview==
There are settings for the kind of Upload user function you want to perform on the "Upload users preview" page.
[[File:Upload users preview 2.0.JPG|thumb|center|Upload users preview in Moodle 2.x]]

===Updating existing accounts===

By default Moodle adds new user accounts and skips existing users lines where the <code>username</code> matches an existing account. Set "Upload Type" to '''Add new and update existing users''', and existing user account will be updated.
*Add all, append number to usernames if needed
*Add new and update existing users
*Update existing users only
There are also fields settings to force password change, allow renames, allow deletes, prevent email address duplicates, standardise usernames and select for bulk operations(new users. updated users, all users).

'''Warning''': errors updating existing accounts can affect your users badly. Be careful when using the options to update.

===Set default user values===

You may be able to set default user field values, if the fields were not included in the uploaded file on this page.

==Upload user results ==
After accepting the preview settings by clicking on "Upload users", you should see the the Upload users results screen.
[[File:Upload users results 2.0.JPG|thumb|center|The 2.0 results screen, everything went well]]
This screen will show you any exceptions or changes that were made to each user in the upload process. For example if you were updating user information, the updated information will be shown. Or if a user was not added that record will be highlighted.

The screen will summarize how many users were uploaded or updated, indicate the number of weak passwords and the number of errors.

==File formats for upload users file==
The upload files have their fields separated by a comma (or other delimiter). The first line contains the valid field names. The rest of the lines (records) contain information about each user.

'':Tip:'' If you are not an expert, avoid special characters in field information like quotes or other commas. Test a file with only one record before a large upload. Remember there are other ways to authenticate users on you site or enroll users in a course.

'':Tip:'' You can use a spread sheet program to create the file with the required columns and fields. Then save the file as "CSV (comma delimited)". These files can be opened with simple text editors for verification.

===Valid upload file for testing===
Here is an example of a simple valid upload file:

<code>username, password, firstname, lastname, email, course1, group1, cohort1 
jonest, verysecret, Tom, Jones, jonest@someplace.edu, math102, Section 1, year 3 
reznort, somesecret, Trent, Reznor, reznort@someplace.edu, math102, Section 3, year 4</code>

===Fields that can be included===
'':Tip:'' We strongly recommend that you test a file that contains fields you proposed to use with one user before attempting a file upload for the first time. demo.moodle.net might be a good place to see if your test file works.

*'''Required fields''':
:<code>username, firstname, lastname, email</code>
:Validity checks are performed for:
#<code>username</code> can only contain alphabetical '''lowercase''' letters , numbers, hypen '-', underscore '_', period '.', or at-sign '@'
#<code>email</code> is in the form: ''name@example.com'' .

*'''Password field''': "password" field is optional if "Create password if needed" setting is chosen (default).
**If included, values should meet the requirements for the site's [[Site_policies#Password_policy|Password policy]]. To force password change for a particular user, set the password field to <code>changeme</code>.
**If omitted, a password will be generated for each user (during the next Cron job) and welcome e-mails sent out (not working in v2.0.2?).
**Note: the text for the welcome e-mail is in the language settings.

*'''Optional fields''': To provide values other than the default include one or more of these
:<code>institution, department, city, country, lang, auth, timezone, idnumber, icq, phone1, phone2, address, url, description, mailformat, maildisplay, htmleditor, autosubscribe</code>
*Country- use a country TWO LETTER CODE
*Some fields have a maximum number of characters that are allowed (notably institution should be '''at most 40 characters''' long). See hints below.
*Maildisplay, htmleditor and autosubscribe can be set from an import screen in Moodle 2.0.

*'''Custom profile field names''': (Optional). xxxxx is the real custom user profile field name (i.e. the unique shortname)
:<code>profile_field_xxxxx</code>
: Create the custom fields BEFORE importing. Use the standard header. The "shortname" for your custom field is xxxxx (NB: as at v2.0.2, the shortname must be all lowercase, otherwise won't be recognised). The first record must include "profile_field_xxxxx".

:'''Example''': To create a custom field "genre", you must write a shortname "genre" in the new field, and write "profile_field_genre" in the header of the .csv file.

: For custom profile fields that are a menu, use the corresponding menu number (index).

:'''Example''': if your custom field is department and there are three choices - HR, Marketing,Training- then HR would be 0, Marketing would be 1, and Training would be 2.

*'''Special fields''': Used for changing of usernames or deleting of users
:<code>oldusername</code>, <code>deleted</code>

*'''Enrolment fields''': (Optional):
:<code>course1, type1, role1, group1, enrolperiod1, course2, type2, role2, group2, enrolperiod2</code> etc.

:*<code>course</code> is the "shortname" of the course, if present the user will be enrolled in those courses.
:* <code>type</code> refers to the role to be used for associated course enrolment. Value 1 is default course role, 2 is legacy Teacher role and 3 is legacy Non-editing Teacher.
:* You can use role field instead to specify roles directly - use either role short name or id (numeric names of roles are not supported).
:* Users may be also assigned to groups in course (group1 in course1, group2 in course2, etc.).
:* A group is identified by name or id (numeric group names are not supported)
:* You can set the enrolment duration, in days, for each course (<code>enrolperiod1</code> for <code>course1</code>, <code>enrolperiod2</code> for <code>course2</code>, etc.).

*'''Cohort field''': (Optional):
:<code>cohort1</code>

:Cohort ids (not names) of existing cohorts must be used

Commas within a field must be encoded as &#44 - the script will decode these back to commas.

For Boolean fields, use <code>0</code> for false and <code>1</code> for true.

To prevent users from receiving a large number of emails from courses or forced subscription forums use the '''maildigest'''. The options for this field are 0 = No digest, 1 = Complete digest and 2 = Digest with just subjects.

==Advanced potentials of Upload user==
===Templates===

''Note: This section needs checking and updating if necessary for Moodle 2.0. Please do so and remove this note when finished.''

The default values are processed as templates in which the following codes are allowed:

* %l - will be replaced by the lastname
* %f - will be replaced by the firstname
* %u - will be replaced by the username
* %% - will be replaced by the %

Between the percent sign (%) and any code letter (l, f or u) the following modifiers are allowed:

* (-) minus sign - the information specified by the code letter will be converted to lowercase
* (+) plus sign - the information specified by the code letter will be converted to UPPERCASE
* (~) tilde sign - the information specified by the code letter will be converted to Title Case
* a decimal number - the information specified by the code letter will be truncated to that many characters

For example, if the firstname is John and the lastname is Doe, the following values will be obtained with the specified templates:

* %l%f = DoeJohn
* %l%1f = DoeJ
* %-l%+f = doeJOHN
* %-f_%-l = john_doe
*<nowiki> http://www.example.com/~%u/</nowiki> results in <nowiki>http://www.example.com/~jdoe/</nowiki> (if the username is jdoe or %-1f%-l)

Template processing is done only on default values, and not on the values retrieved from the CSV file.

In order to create correct Moodle usernames, the username is always converted to lowercase. Moreover, if the "Allow extended characters in usernames" option in the Site policies page is off, characters different to letters, digits, dash (-) and dot (.) are removed. For example if the firstname is John Jr. and the lastname is Doe, the username %-f_%-l will produce john jr._doe when Allow extended characters in usernames is on, and johnjr.doe when off.

When the "New username duplicate handling" setting is set to Append counter, an auto-increment counter will be append to duplicate usernames produced by the template. For example, if the CSV file contains the users named John Doe, Jane Doe and Jenny Doe without explicit usernames, the default username is %-1f%-l and New username duplicate handling is set to Append counter, then the usernames produced will be jdoe, jdoe2 and jdoe3.

===Deleting accounts===

If the <code>deleted</code> field is present, users with value 1 for it will be deleted. In this case, all the fields may be omitted, except for <code>username</code>. After uploading the file, be sure to change the "Upload type" to "Update existing users only" and the "Allow deletes" option to "Yes".

Deleting and uploading accounts could be done with a single CSV file. For example, the following file will add the user Tom Jones and delete the user reznort:

username, firstname, lastname, deleted
jonest, Tom, Jones, 0
reznort, , , 1

==Encoding file format==
On the initial Upload user screen, you may select the file encoding format from a pull down list. These include UTF-8 (the default), ASCII, ISO-8859-1 to ISO-8859-11 or any one of over 36 formats.

==Hints==

===Spreadsheet===

If you use a spreadsheet program such as Excel to create your .csv file, check the resulting output in a text editor before you upload it. It is possible to get trailing commas on each line from an empty field if you have added and deleted columns of information prior to saving the final file. Also check the character encoding. A csv file is a simple text file (ASCII or Unicode) that can be used to upload user accounts.

Excel translates passwords that begin with - (minus) or + (plus) as zero. Even when saving as .csv and saying "Yes" to "Keep this format, and leave out any incompatible features." Check for this before uploading, as a zero halts the upload process.

If you use a formula in Excel to create fields (for example, the concatenate function to create a user name), then remember to copy the cells with the formula and use special paste with values checked to make them into an acceptable data for a csv file.

===Country===
The country should be written as a two letter code, in capitals. For example, use BE for Belgium or NL for the Netherlands. Using "be" or "nl" as a country code will result in a database error.
:''Tip:'' If you are having trouble working out the two-letter code for a country, you can consult this Moodle source code file /moodle/lang/en_utf8/countries.php [http://cvs.moodle.org/moodle/lang/en_utf8/countries.php?view=markup&pathrev=MOODLE_19_STABLE or click here for a 1.9 STABLE list].
ISO Website: [http://www.iso.org/iso/country_codes/iso_3166_code_lists/english_country_names_and_code_elements.htm]
===Field size limits===
Some fields have maximum character lengths. Typically the file will import to the preview list screen but not finish the process. Turn on debug to see the fields that are too long. Common fields to cause problems are "Institution" which is limited to 40 characters, and "City", also limited. The error will be "User not added - error".

===All fields listed here===
:All the fields that are valid are listed below, except for any custom fields you may have created.
firstname, lastname, username, email, city, country, lang, timezone, mailformat, maildisplay, maildigest, htmleditor, ajax, autosubscribe ,institution, department, idnumber, skype , msn, aim, yahoo, icq, phone1, phone2, address, url, description, descriptionformat, password, auth, oldusername , deleted, course1, course2, course3, course4

== See also ==

*[[Flat file]] enrolment
* [[User profile fields]] for details of how to include data about custom user profile fields in the upload users file

Using Moodle forum discussions:
*[http://moodle.org/mod/forum/discuss.php?d=36851 Can I auto enroll from Excel?]
*[http://moodle.org/mod/forum/discuss.php?d=97903 Uploading users to custom roles]
*[http://moodle.org/mod/forum/discuss.php?d=181259 User upload option: standardise usernames]
*[http://moodle.org/mod/forum/discuss.php?d=144569 Matriculacion con flat file csv] - discussion in Spanish

[[fr:Importer des utilisateurs]]
[[ja:ユーザのアップロード]]
[[de:Nutzerliste hochladen]]

Add a new user

2012-06-20T03:04:01Z

Poltawski: remove AJAX and Javascript MDL-32908

{{Accounts}}
An administrator or manager (or any other user with the capability [[Capabilities/moodle/user:create|moodle/user:create]]) can create new user accounts in ''Settings > Site administration > Users > Accounts > Add a new user''. (To add users in bulk, see [[Upload users]].)

[[File:Addanewuser.png]]

==General==

===Username===
The user will use this username to log in to the Moodle instance. It needs to be unique. This may be changed. A user's name can only contain alphabetical letters in lowercase, numbers, hyphen '-', underscore '_', period '.', or an at character '@'.

===Authentication method===
The setting specifies how Moodle will check whether the user's specified password is correct.

Accounts created by an administrator use the '''Manual Accounts''' method, and accounts created by the user themselves using the email sign-up method use the E-mail based self-registration method.

===Suspended account===

Suspended user accounts cannot log in or use web services, and any outgoing messages are discarded.

===Password===
This is the user's password. It is subject to the password policy in [[Site policies]]. A user can change their password by the ''Settings block > My Profile settings > Change password'' link.

===First Name===
The user's first name. It is displayed along with the last name in messages, forum posts, participants list, reports and anywhere where something about the user is shows on the page.

===Surname===
The user's surname. It is displayed along with the first name in messages, forum posts, participants list, reports and anywhere where something about the user is shows on the page.

===Email address===
Password reset notices, forum digests and other messages are sent to this email address from the Moodle site.

===Email display===
This setting controls who can see the user's email address.

===Email format===
This setting can be used such that Moodle will send text-only emails to the user.

===Email digest type===
This setting set whether the user will receive an email for each new forum post in subscribed forums, or if new posts should be sent once per day in a digest, and which type of digest.
* No digest (one receives individual emails),
* Complete (a single digest daily) or
* Subjects (a single digest daily with only the post topics included).

===Forum auto-subscribe===
If a user subscribes to a forum, new posts will be sent in the digest as specified. This setting sets whether a user is automatically subscribed to forums or if a manual click on the subscription button in each forum is required.

===Forum tracking===
THis setting specifies whether new posts written since the user's last visit should be highlighted as such.

===When editing text===
This setting specifies whether the user prefers to see the WYSIWYG text editor or just a plain text box.

===Screen Reader===
Enabling this setting will improve the display of Moodle to make it more compatible with screen readers.

===City/town===
The user's city or town

===Country===
The user's country

Note: City and country defaults may be set in ''Settings > Site administration > Location > Location settings''.

===Timezone===
This setting is used to adjust the times of messages and assignment/quiz due dates to match the user's local time

===Preferred language===
This will cause the Moodle interface to be displayed in the specified language. (See [[Language packs]])

Note: Content will not be translated automatically, but if multi-language content is entered the appropriate language content will be displayed, if available.

===Description===
Information about the user that other users can see.

==User Picture==
The user's picture can be displayed next to the user's name next to any content he/she has posted in Moodle activities such as the forum. See [[User pictures]] and [[Gravatars]] for details.

==Interests==
The list of interests can be used as a way of connecting users with similar interests. [[Tags]] must be enabled on the site.

==Optional==
There are several optional fields that come with an standard install. These include:
Web Page, ICA number, Skype ID, AIM ID, Yahoo ID, MSN ID, ID number, Institution, Department, Phone, Mobile Phone, Address.

The site administrator may [[User profile fields|add more custom fields]] and/or turn off any of these "optional" fields.

[[de:Nutzer/in neu anlegen]]

Update profile

2012-06-20T03:03:36Z

Poltawski: remove AJAX and Javascript MDL-32908

{{Accounts}}
==Editing Your Profile ==

Administrators can update user profiles via ''Administration > Users > Accounts > Add a new user'' or ''Browse list of users'' and individual users may update their profiles by choosing the ''Edit profile'' link from ''Settings>My profile settings''

The fields are divided into 3 sections - General, Picture & Optional which are all explained below. Note that some settings are 'advanced', so you may need to click the 'Show Advanced' button on the right to see all the settings. The advanced settings are indicated below.

Remember to click 'Update profile' when you have finished.

=== General ===

The first section contains fields that must be completed:

'''First name & Surname'''

These are self-explanatory. These names will identify you everywhere in your Moodle courses.

'''Email address'''

The email address should be an address that you check regularly. It is used for acknowledgements and announcements from Moodle, including messages from Forums that you are subscribed to. It is also the address that is displayed to other users of Moodle, depending on your 'Email display' setting (below).

'''Email display'''

This controls the visibility of your email address to others. The three settings are self-explanatory but please note 'Hide my email address from everyone' only hides it from students. Teaching staff and other staff with editing access will always be able to see your email address.

'''Email format (advanced)'''

There are two formats: "Pretty HTML format" (messages will be formatted) and "Plain text format" (plain text with no formatting).

'''Email digest type (advanced)'''

This setting determines how you receive any posts from Forums to which you are subscribed, allowing you to receive messages individually or on a daily basis.

'''Forum auto-subscribe (advanced)'''

This setting lets you decide if you want email copies of posts that are added to forums. If you set this to subscribe, the system will automatically email you copies of new posts in forums that you post in, unless you manually override it when posting.

'''Forum tracking (advanced)'''

Enabling forum tracking means highlighting the posts you have not read yet, which should improve your forum navigation.

'''When editing text (advanced)'''

This can usually be left on "Use HTML editor (some browsers only)". This allows for text formatting options, but requires newer browsers. If you find your browser is not letting you edit text, change this setting to "Use standard web forms".

'''Screen Reader (advanced)'''

If you use a screen reader, this setting should be set to 'Yes'. (A screen reader is a form of 'assistive technology' used by blind and partially-sighted users to interpret what is displayed on the screen).

The screenreader variable is used in:

* /mod/chat/ - if screenreader is enable, chat window will be set to use gui_basic
* /mod/course/report/progress/ - check for svg to rotate text
* /admin/mnet/mnet_themes.html - use to ignore or print theme images
* /user/ - set the value for screenreader
* /grade/report/grader/ - use to set fixed layout
* /question/type/multianswer/ - used to print feedback icon and print an gap icon for question (MDL-7497)

'''City/town & Country'''

Add your location.

'''Timezone'''

This field is used to convert time-related messages on the system (such as assignment deadlines) from the local timezone (the time in London) to the correct time in whichever zone you have selected.

'''Preferred language and theme (advanced)'''

You can view Moodle in several different languages and colour themes, which you can select via these two options. Note: changing the preferred language only affects the Moodle interface, not the course content!

'''Description'''

In this field you can enter some text about yourself, be it information about your studies, hobbies, qualifications or anything else.

=== User picture ===

This section is optional and allows you to choose your own profile picture. Your current picture is shown, if you have already chosen one.

Note: If the admin has enabled it in ''Settings > Site Administration > Users > Permissions > User policies'', a gravatar you might have attached to your email account will appear as your profile image if you don't upload a different one. See [[Gravatars]] for details.

'''New picture'''

The "Choose a file" button allows you to choose a new picture for your profile. The picture must be in JPG or PNG format (ie the names will usually end in .jpg or .png).

To upload an image, click the "Upload a file" button from the list in the [[File_picker]], and select the image from your hard disk.

NOTE: Make sure that the file is not larger than the maximum size listed, or it will not be uploaded.

Then click "Update Profile" at the bottom - the image file will be cropped to a square and resized down to 100x100 pixels.

When you are taken back to your profile page, the image might not appear to have changed. If this is so, just use the "Reload" button in your browser.
==Interests==
Use tags here to display your interests on your profile page.

=== Optional ===

There are several optional fields (all advanced) allowing you to add further details to your profile such as contact details and your website.

===Custom Profile Categories===
If any custom user profile categories and fields have been created on your Moodle site, they will be listed at the bottom of the [[User profile fields|Admin >Accounts>User profile fields]]

==Updating a user profile==

Users with the capability [[Capabilities/moodle/user:update|moodle/user:update]] are able to update another user's profile i.e. in addition to being able to edit the profile, all settings (username, password, authentication method, force new password etc.) may be changed.

==Account disabling==

An account may be disabled by setting the authentication method to "[[No login]]". The account email may not be used to create another account.

==See also==

*[[User profiles]]

[[fr:Modifier le profil]]
[[de:Nutzerprofil aktualisieren]]

Google OAuth 2.0 setup

2012-06-07T06:26:42Z

Poltawski: Converting to thumnails. This view still sucks though. I'm not a mediawiki guru.

Prior to Moodle 2.3, Google Docs and Picasa repository plugins and portfolio plugins could be used without any configuration or registration with Google. In April 2012, [http://googledevelopers.blogspot.com/2012/04/changes-to-deprecation-policies-and-api.html Google announced] to web application developers that they would be deprecating the service which Moodle was using to communicate with Google and strongly advised developers to move away from it. As a response to this change with Google's service, Moodle switched to use a new system for communicating with Google called 'OAuth 2.0'. The OAuth 2.0 system providers and a better security system and more friendly experience to Moodle users, though it requires some additional configuration in Moodle.

==Registering with Google==
Each Moodle site now needs to be registered with Google in order to use the Google Docs or Picasa plugins. The following will guide you through the process of registering with Google.

# You will need to be signed into a google account
# Visit the [Google API's Console https://code.google.com/apis/console#access]
# You will be asked to create a project if this is your first time using this form. [[Image:google_oauth1.png|thumb|3. creating API Project]]
# You need to click the button marked 'Create an OAuth 2.0 client ID..' [[File:google_oauth2.png|thumb|4. creating an OAuth 2.0 Client ID]]
# You will be asked to enter branding information including a 'Product name' and 'Product logo'. By providing a descriptive name and link to distinct image then your users will know they are signing into the correct place. [[File:google_oauth3.png|thumb|5. client Settings]]
# Next you will be asked for 'Client ID Settings'
## For Application type, select 'Web application'
## Next to 'Your site or hostname' click '(more options)'
## In 'Authorized Redirect URIs' enter the URL which was provided in your Moodle settings page. (usually http://yourmoodle/admin/oauth2callback.php)
## In 'Authorized JavaScript Origins' leave the field blank [[File:google_oauth4.png|thumb|9. callback options]]
# Click 'Create client ID'
# Your site is now registered with Google and you will be presented with your details. [[File:google_oauth5.png|thumb|12. registered details]]
# Enter the 'Client ID' and 'Client secret' provided into your Moodle settings page

==Resulting Authorisation Screen==
Once configured, Google will present Moodle users with a nice authorisation screen with your moodle name and logo for your users to authorise:
[[File:google_oauth6.png]]

Google OAuth 2.0 setup

2012-06-07T06:17:16Z

Poltawski: slightly improved the initial sentence so it sounds less like I was smoking something whilst authoring it. ;-)

Prior to Moodle 2.3, Google Docs and Picasa repository plugins and portfolio plugins could be used without any configuration or registration with Google. In April 2012, [http://googledevelopers.blogspot.com/2012/04/changes-to-deprecation-policies-and-api.html Google announced] to web application developers that they would be deprecating the service which Moodle was using to communicate with Google and strongly advised developers to move away from it. As a response to this change with Google's service, Moodle switched to use a new system for communicating with Google called 'OAuth 2.0'. The OAuth 2.0 system providers and a better security system and more friendly experience to Moodle users, though it requires some additional configuration in Moodle.

==Registering with Google==
Each Moodle site now needs to be registered with Google in order to use the Google Docs or Picasa plugins. The following will guide you through the process of registering with Google.

# You will need to be signed into a google account
# Visit the [Google API's Console https://code.google.com/apis/console#access]
# You will be asked to create a project if this is your first time using this form. [[File:google_oauth1.png]]
# You need to click the button marked 'Create an OAuth 2.0 client ID..' [[File:google_oauth2.png]]
# You will be asked to enter branding information including a 'Product name' and 'Product logo'. By providing a descriptive name and link to distinct image then your users will know they are signing into the correct place. [[File:google_oauth3.png]]
# Next you will be asked for 'Client ID Settings'
## For Application type, select 'Web application'
## Next to 'Your site or hostname' click '(more options)'
## In 'Authorized Redirect URIs' enter the URL which was provided in your Moodle settings page. (usually http://yourmoodle/admin/oauth2callback.php)
## In 'Authorized JavaScript Origins' leave the field blank [[File:google_oauth4.png]]
# Click 'Create client ID'
# Your site is now registered with Google and you will be presented with your details. [[File:google_oauth5.png]]
# Enter the 'Client ID' and 'Client secret' provided into your Moodle settings page

==Resulting Authorisation Screen==
Once configured, Google will present Moodle users with a nice authorisation screen with your moodle name and logo for your users to authorise:
[[File:google_oauth6.png]]

Google OAuth 2.0 setup

2012-06-04T12:47:20Z

Poltawski:

Prior to Moodle 2.3, Google Docs and Picasa repository plugins and portfolio plugins could be used without any configuration or registration with Google. In April 2012, [http://googledevelopers.blogspot.com/2012/04/changes-to-deprecation-policies-and-api.html Google Announced] to web application developers that they would be deprecated the service which Moodle was using to communicate with Google and strongly advised developers to move away from it. As a response to this change with Google's service, Moodle switched to use a new system for communicating with Google called 'OAuth 2.0', starting with Moodle 2.3. The OAuth 2.0 system providers and a better security system and more friendly experience to Moodle users, though it requires some additional configuration in Moodle.

==Registering with Google==
Each Moodle site now needs to be registered with Google in order to use the Google Docs or Picasa plugins. The following will guide you through the process of registering with Google.

# You will need to be signed into a google account
# Visit the [Google API's Console https://code.google.com/apis/console#access]
# You will be asked to create a project if this is your first time using this form. [[File:google_oauth1.png]]
# You need to click the button marked 'Create an OAuth 2.0 client ID..' [[File:google_oauth2.png]]
# You will be asked to enter branding information including a 'Product name' and 'Product logo'. By providing a descriptive name and link to distinct image then your users will know they are signing into the correct place. [[File:google_oauth3.png]]
# Next you will be asked for 'Client ID Settings'
## For Application type, select 'Web application'
## Next to 'Your site or hostname' click '(more options)'
## In 'Authorized Redirect URIs' enter the URL which was provided in your Moodle settings page. (usually http://yourmoodle/admin/oauth2callback.php)
## In 'Authorized JavaScript Origins' leave the field blank [[File:google_oauth4.png]]
# Click 'Create client ID'
# Your site is now registered with Google and you will be presented with your details. [[File:google_oauth5.png]]
# Enter the 'Client ID' and 'Client secret' provided into your Moodle settings page

==Resulting Authorisation Screen==
Once configured, Google will present Moodle users with a nice authorisation screen with your moodle name and logo for your users to authorise:
[[File:google_oauth6.png]]

Google OAuth 2.0 setup

2012-06-04T12:41:51Z

Poltawski: /* Registering with Google */

Prior to Moodle 2.3, Google Docs and Picasa repository plugins and portfolio plugins could be used without any configuration or registration with Google. In April 2012, [http://googledevelopers.blogspot.com.au/2012/04/changes-to-deprecation-policies-and-api.html Google Announced] to web application developers that they would be deprecated the service which Moodle was using to communicate with Google and strongly advised developers to move away from it. As a response to this change with Google's service, Moodle switched to use a new system for communicating with Google called 'OAuth 2.0', starting with Moodle 2.3. The OAuth 2.0 system providers and a better security system and more friendly experience to Moodle users, though it requires some additional configuration in Moodle.

==Registering with Google==
Each Moodle site now needs to be registered with Google in order to use the Google Docs or Picasa plugins. The following will guide you through the process of registering with Google.

# You will need to be signed into a google account
# Visit the [Google API's Console https://code.google.com/apis/console#access]
# You will be asked to create a project if this is your first time using this form. [[File:google_oauth1.png]]
# You need to click the button marked 'Create an OAuth 2.0 client ID..' [[File:google_oauth2.png]]
# You will be asked to enter branding information including a 'Product name' and 'Product logo'. By providing a descriptive name and link to distinct image then your users will know they are signing into the correct place. [[File:google_oauth3.png]]
# Next you will be asked for 'Client ID Settings'
## For Application type, select 'Web application'
## Next to 'Your site or hostname' click '(more options)'
## In 'Authorized Redirect URIs' enter the URL which was provided in your Moodle settings page. (usually http://yourmoodle/admin/oauth2callback.php)
## In 'Authorized JavaScript Origins' leave the field blank [[File:google_oauth4.png]]
# Click 'Create client ID'
# Your site is now registered with Google and you will be presented with your details. [[File:google_oauth5.png]]
# Enter the 'Client ID' and 'Client secret' provided into your Moodle settings page

==Resulting Authorisation Screen==
Once configured, Google will present Moodle users with a nice authorisation screen with your moodle name and logo for your users to authorise:
[[File:google_oauth6.png]]

Google OAuth 2.0 setup

2012-06-04T12:40:48Z

Poltawski: /* Registering with Google */

Prior to Moodle 2.3, Google Docs and Picasa repository plugins and portfolio plugins could be used without any configuration or registration with Google. In April 2012, [http://googledevelopers.blogspot.com.au/2012/04/changes-to-deprecation-policies-and-api.html Google Announced] to web application developers that they would be deprecated the service which Moodle was using to communicate with Google and strongly advised developers to move away from it. As a response to this change with Google's service, Moodle switched to use a new system for communicating with Google called 'OAuth 2.0', starting with Moodle 2.3. The OAuth 2.0 system providers and a better security system and more friendly experience to Moodle users, though it requires some additional configuration in Moodle.

==Registering with Google==
Each Moodle site now needs to be registered with Google in order to use the Google Docs or Picasa plugins. The following will guide you through the process of registering with Google.

# You will need to be signed into a google account
# Visit the [Google API's Console https://code.google.com/apis/console#access]
# You will be asked to create a project if this is your first time using this form. [[File:google_oauth1.png]]
# You need to click the button marked 'Create an OAuth 2.0 client ID..' [[File:google_oauth2.png]]
# You will be asked to enter branding information including a 'Product name' and 'Product logo'. By providing a descriptive name and link to distinct image then your users will know they are signing into the correct place. [[File:google_oauth3.png]]
# Next you will be asked for 'Client ID Settings'
## For Application type, select 'Web application'
## Next to 'Your site or hostname' click '(more options)'
## In 'Authorized Redirect URIs' enter the URL which was provided in your Moodle settings page. (usually http://yourmoodle/admin/oauth2callback.php)
## In 'Authorized JavaScript Origins' leave the field blank [[File:google_oauth4.png]]
# Click 'Create client ID'
# Your site is now registered with Google and you will be presented with your details. [[File:google_oauth5.png]]
# Enter the 'Client ID' and 'Client secret' provided into your Moodle settings page

Once configured, Google will present Moodle users with a nice authorisation screen with your moodle name and logo for your users to authorise:
[[File:google_oauth6.png]]

Fitxer:google oauth6.png

2012-06-04T12:38:50Z

Poltawski:

Google OAuth 2.0 setup

2012-06-04T12:34:09Z

Poltawski:

Prior to Moodle 2.3, Google Docs and Picasa repository plugins and portfolio plugins could be used without any configuration or registration with Google. In April 2012, [http://googledevelopers.blogspot.com.au/2012/04/changes-to-deprecation-policies-and-api.html Google Announced] to web application developers that they would be deprecated the service which Moodle was using to communicate with Google and strongly advised developers to move away from it. As a response to this change with Google's service, Moodle switched to use a new system for communicating with Google called 'OAuth 2.0', starting with Moodle 2.3. The OAuth 2.0 system providers and a better security system and more friendly experience to Moodle users, though it requires some additional configuration in Moodle.

==Registering with Google==
Each Moodle site now needs to be registered with Google in order to use the Google Docs or Picasa plugins. The following will guide you through the process of registering with Google.

# You will need to be signed into a google account
# Visit the [Google API's Console https://code.google.com/apis/console#access]
# You will be asked to create a project if this is your first time using this form. [[File:google_oauth1.png]]
# You need to click the button marked 'Create an OAuth 2.0 client ID..' [[File:google_oauth2.png]]
# You will be asked to enter branding information including a 'Product name' and 'Product logo'. By providing a descriptive name and link to distinct image then your users will know they are signing into the correct place. [[File:google_oauth3.png]]
# Next you will be asked for 'Client ID Settings'
## For Application type, select 'Web application'
## Next to 'Your site or hostname' click '(more options)'
## In 'Authorized Redirect URIs' enter the URL which was provided in your Moodle settings page. (usually http://yourmoodle/admin/oauth2callback.php)
## In 'Authorized JavaScript Origins' leave the field blank [[File:google_oauth4.png]]
# Click 'Create client ID'
# Your site is now registered with Google and you will be presented with your details. [[File:google_oauth5.png]]
# Enter the 'Client ID' and 'Client secret' provided into your Moodle settings page

Google OAuth 2.0 setup

2012-06-04T12:33:41Z

Poltawski:

Prior to Moodle 2.3, Google Docs and Picasa repository plugins and portfolio plugins could be used without any configuration or registration with Google. In April 2012, [http://googledevelopers.blogspot.com.au/2012/04/changes-to-deprecation-policies-and-api.html Google Announced] to web application developers that they would be deprecated the service which Moodle was using to communicate with Google and strongly advised developers to move away from it. As a response to this change with Google's service, Moodle switched to use a new system for communicating with Google called 'OAuth 2.0', starting with Moodle 2.3. The OAuth 2.0 system providers and a better security system and more friendly experience to Moodle users, though it requires some additional configuration in Moodle.

==Registering with Google==
Each Moodle site now needs to be registered with Google in order to use the Google Docs or Picasa plugins. The following will guide you through the process of registering with Google.

# You will need to be signed into a google account
# Visit the [Google API's Console https://code.google.com/apis/console#access]
# You will be asked to create a project if this is your first time using this form. [[File:google_oauth1.png]]
# You need to click the button marked 'Create an OAuth 2.0 client ID..' [[File:google_oauth2.png]]
# You will be asked to enter branding information including a 'Product name' and 'Product logo'. By providing a descriptive name and link to distinct image then your users will know they are signing into the correct place. [[File:google_oauth3.png]
# Next you will be asked for 'Client ID Settings'
## For Application type, select 'Web application'
## Next to 'Your site or hostname' click '(more options)'
## In 'Authorized Redirect URIs' enter the URL which was provided in your Moodle settings page. (usually http://yourmoodle/admin/oauth2callback.php)
## In 'Authorized JavaScript Origins' leave the field blank [[File:google_oauth4.png]
# Click 'Create client ID'
# Your site is now registered with Google and you will be presented with your details. [[File:google_oauth5.png]
# Enter the 'Client ID' and 'Client secret' provided into your Moodle settings page

Fitxer:google oauth5.png

2012-06-04T12:32:05Z

Poltawski:

Fitxer:google oauth4.png

2012-06-04T12:31:43Z

Poltawski:

Fitxer:google oauth3.png

2012-06-04T12:31:12Z

Poltawski:

Fitxer:google oauth2.png

2012-06-04T12:30:56Z

Poltawski:

Fitxer:google oauth1.png

2012-06-04T12:30:33Z

Poltawski:

Google OAuth 2.0 setup

2012-06-04T12:21:21Z

Poltawski: First draft of oauth2 settings This is a difficult page to write because it implicitly contains jargon.

Prior to Moodle 2.3, Google Docs and Picasa repository plugins and portfolio plugins could be used without any configuration or registration with Google. In April 2012, [http://googledevelopers.blogspot.com.au/2012/04/changes-to-deprecation-policies-and-api.html Google Announced] to web application developers that they would be deprecated the service which Moodle was using to communicate with Google and strongly advised developers to move away from it. As a response to this change with Google's service, Moodle switched to use a new system for communicating with Google called 'OAuth 2.0', starting with Moodle 2.3. The OAuth 2.0 system providers and a better security system and more friendly experience to Moodle users, though it requires some additional configuration in Moodle.

==Registering with Google==
Each Moodle site now needs to be registered with Google in order to use the Google Docs or Picasa plugins. The following will guide you through the process of registering with Google.

# You will need to be signed into a google account
# Visit the [Google API's Console https://code.google.com/apis/console#access]
# You will be asked to create a project if this is your first time using this form.
# You need to click the button marked 'Create an OAuth 2.0 client ID..'
# You will be asked to enter branding information including a 'Product name' and 'Product logo'. By providing a descriptive name and link to distinct image then your users will know they are signing into the correct place.
# Next you will be asked for 'Client ID Settings'
## For Application type, select 'Web application'
## Next to 'Your site or hostname' click '(more options)'
## In 'Authorized Redirect URIs' enter the URL which was provided in your Moodle settings page. (usually http://yourmoodle/admin/oauth2callback.php)
## In 'Authorized JavaScript Origins' leave the field blank
# Click 'Create client ID'
# Your site is now registered with Google and you will be presented with your details.
# Enter the 'Client ID' and 'Client secret' provided into your Moodle settings page

Upgrading to Moodle 2.3

2012-05-24T08:43:54Z

Poltawski: added a comment about 2x assignment modules, please expand this..

{{Installing Moodle}}
Note: You can only upgrade to Moodle 2.3 from Moodle 2.2 or later.

'''We advise that you test the upgrade first on a COPY of your production site, to make sure it works as you expect.'''

==System requirements==

* PHP must be '''5.3.2''' or later
** Required PHP extensions: iconv, curl, ctype, zip, simplexml, spl, pcre, dom, xml, json
** Required PHP memory_limit at least 40MB (64MB or more recommended if you have a choice)
* Databases should be one of the following:
** MySQL 5.0.25 or later (InnoDB storage engine highly recommended)
** PostgreSQL 8.3 or later
** Oracle 10.2 or later
** MS SQL 2005 or later
* Any standards-supporting browser from the past few years, for example:
** Firefox 3 or later
** Safari 3 or later
** Google Chrome 4 or later
** Opera 9 or later
** MS Internet Explorer 7 or later

Note: The above system requirements are unchanged from Moodle 2.1.

Minimum browser: Firefox 4, Internet Explorer 8, Safari 5 (New!)

==Before upgrading please... ==

'''NOTE''': The upgrade process will irreversibly modify the contents of your database '''and''' your moodledata file storage area. If something goes wrong you '''cannot''' go back. It is vital that you take good backups of both moodledata and the database in case you have problems with the upgrade. If you are not sure how see [[Site backup]] or ask in the moodle.org forums (explaining what your operating system is).

* Read the [[:dev:Moodle 2.3 release notes|Moodle 2.3 release notes]] and check the [[:Category:New features|list of new features]]
* Check your site to make sure it meets all system requirements for 2.3 in ''Settings > Site administration > Server > [[Environment]]''
* '''Do a full database backup!'''
* '''Do a full moodledata backup'''
* '''Check your backups carefully'''
* Remember to purge PHP cache if using any PHP accelerator

==Possible issues that may affect you==

=== Two assignment modules ===

A new assignment module has been added in Moodle 2.3. The old assignment module is still available and sites which have upgraded from previous versions will have both versions available.

''Please add items here...''

==Checking database schema - old sites==

If your Moodle site has been upgraded through many prior versions it is possible that there will be some problems with the database schema (compared to a fresh 2.0 installation). This may cause the upgrade to fail. If your site started life prior to Moodle 2.0 it is a very good idea to check and correct the database schema before upgrading. See [[Verify Database Schema]]. You should also run the database integrity checks in the XMLDB editor, see the 'See also' for a link to extra scripts to check for other discrepancies.

==Now upgrade==

Once you have satisfied the requirements for Moodle 2.3, follow the instructions on the [[Upgrading|upgrading]] page.

On Linux servers, Moodle 2.3 supports running the [[CLI|upgrade from the command line]], rather than through a web browser. This is likely to be more reliable, particularly for large sites.

==After upgrade==

The config.php file from your 2.0 installation should work fine but if you take a look at config-dist.php that came with Moodle 2.0 there are more/different options available (e.g. database drivers and settings). It's a good idea to map your old config.php settings to a new one based on the 2.3 config-dist.php.

==See also==

* [[dev:Moodle 2.3 release notes|Moodle 2.3 release notes]]

[[fr:Mise à jour à Moodle 2.3]]
[[ja:Moodle2.3へのアップグレード]]

lib/formslib.php Usage

2011-03-15T14:00:14Z

Poltawski: added a note about ordering of get_data/is_validated as there may be a bug here

{{Formslib}}
==Usage of Formslib==

There are many phpdoc style comments in lib/formslib.php

course/edit.php and the included course/edit_form.php provide a good example of usage of this library.

Also see the PEAR docs for [http://pear.php.net/package/HTML_QuickForm/ HTML_QuickForm docs] I found this [http://pear.php.net/manual/en/package.html.html-quickform.tutorial.php quick tutorial] and this [http://www.midnighthax.com/quickform.php slightly longer one] particularly useful.

We created some special wrapper functions for moodle. Function $mform->get_data() returns an object with the contents of the submitted data or returns null if no data has been submitted or validation fails.

===Basic Usage in A Normal Page===

Generally the structure of a page with a form on it looks like this :

<code php>
require_once('pathtoformdescription');
//you'll process some page parameters at the top here and get the info about
//what instance of your module and what course you're in etc. Make sure you
//include hidden variable in your forms which have their defaults set in set_data
//which pass these variables from page to page

$mform = new yourmod_formfunction_form();//name of the form you defined in file above.
//default 'action' for form is strip_querystring(qualified_me())
if ($mform->is_cancelled()){
//you need this section if you have a cancel button on your form
//here you tell php what to do if your user presses cancel
//probably a redirect is called for!
// PLEASE NOTE: is_cancelled() should be called before get_data(), as this may return true
} else if ($fromform=$mform->get_data()){
//this branch is where you process validated data.

} else {
// this branch is executed if the form is submitted but the data doesn't validate and the form should be redisplayed
// or on the first display of the form.
//setup strings for heading
print_header_simple($streditinga, '',
"<a href=\"$CFG->wwwroot/mod/$module->name/index.php?id=$course->id\">$strmodulenameplural</a> ->
$strnav $streditinga", $mform->focus(), "", false);
//notice use of $mform->focus() above which puts the cursor
//in the first form field or the first field with an error.

//call to print_heading_with_help or print_heading? then :

//put data you want to fill out in the form into array $toform here then :

$mform->set_data($toform);
$mform->display();
print_footer($course);

}
</code>

You are encouraged to look at '''lib/formslib.php''' to see what additional functions and parameters are available. Available functions are well commented.

===Defining Your Form Class===

The form class tells us about the structure of the form. You are encouraged to put this in a file called {function}_form.php probably in the same folder in which the page that uses it is located. The name of your class should be {modname}_{function}_form eg. forum_post_form or course_edit_form. These classes will extend class moodleform.

Note the name you give the class is used as the id attribute of your form in html (any trailing '_form' is chopped off'). Your form class name should be unique in order for it to be selectable in CSS by theme designers who may want to tweak the css just for that form.

====definition()====

[[Development:lib/formslib.php_Form_Definition|Help is here for defining your form]] by defining a function definition() in your form class that sets up your form structure.

===Use in Activity Modules Add / Update Forms===

Syntax is the same in activity modules to create your update / add page. We are still supporting mod.html but if you want to use the new formslib then you can in Moodle 1.8 just include in your module directory the file mod_form.php instead of mod.html and it will be automatically detected. Inside this file you define a class with class name '{modname}__mod_form' which extends the class 'moodleform_mod'. See many examples of the core modules which have been converted to use formslib already.

====defaults_preprocessing====

For activity modules you use the same syntax to define your form. You may also want to override method defaults_preprocessing this can be used to take the data from the data base and tell the form how to fill out defaults in the form with this data. For example in the forum module in forum/mod_form.php we needed to tick an enable check box if a date had been selected in the date select. Normally data is loaded from the database and directly loaded into form fields with the same name as the database record you only need to use defaults_preprocessing if there isn't this one to one relationship. Another example is the lesson/mod_form.php which takes the data from the database and unserializes it. choice/mod_form.php shows an exampe of loading data from another db table referred to by a foreign key, to include in the form.

====Post Processing Still Done in lib.php Functions====

Post processing of data is done in lib.php functions modname_add_instance and modname_update_instance after the data has been validated. When migrating a form often little changes need to be made in the post processing. An exception is that date and date_time_selector fields automatically have their submitted data turned into timestamps so you don't need to do this in your add and update functions anymore.

====Automatically Including Standard Activity Module Form Elements====

Standard activity module form elements are automatically included using the moodleform_mod method standard_coursemodule_elements(). The default is to include a visibility and groupsmode select box and to include all necessary hidden fields. You can pass a parameter false to tell the method that your module doesn't support groups and so you don't want the groupsmode select button.

[[Category:Formslib]]

Assign roles

2011-02-21T15:57:14Z

Poltawski: clarify course category permissions inherentance

{{Roles}}

==Locations for assigning roles==

[[Image:Assign roles.png|thumb|Assign roles in Moodle 1.9]]
Assigning roles is done for/in a particular context. A site and course are examples of two different contexts. While the process is similar for each context, the approach to role assignment page may be different. Here are several contexts and ways to find the assign roles.

*System context: ''Site Administration > Users > Permissions > Assign system roles'' (this context is named "site" in Moodle 1.7)
*Front page context: ''Site Administration > Front Page > Front Page roles'' (in Moodle 1.8 onwards)
*Course category context: Assign roles link in course categories page
*Course context: Assign roles link in course administration block
*Module context: "Locally assigned roles" tab in editing activity page
*Block context: Assign roles link in course block (with editing turned on)
*User context: Roles tab in user profile page

{{Moodle 1.9}}In Moodle 1.9 onwards, the assign roles page lists the names of users assigned to each role (unless there are more than 10 users, in which case this is stated).

==Contexts==

By assigning a role to a user in a certain context, you grant them the permissions contained in that role for the current context and all lower contexts.

The list of contexts in hierarchical order is as follows:

[[Image:Moodle-contexts-1.8.png|right|thumbnail|200px|A diagram of the contexts in Moodle. Click on the diagram to see a more detailed view of it.]]

*System (no parent)
*Front page (parent = system) - Moodle 1.8 onwards
*Course category (parent = parent category or system)
*Course (parent = category or system)
*Module (parent = course or system) - Moodle 1.8 onwards
*Block (parent = course or system) - Moodle 1.8 onwards
*User (parent = system)

Inheritance will kick in if a role is assigned at a higher level. For example if a user is assigned a Teacher role in a particular course category then the user will have this role in ALL courses within the category.

Roles will only work if the role assignment is made in the correct context. For example, a Teacher role should be assigned in the course or course category context, a Forum moderator for a particular forum should be assigned in the module context.

The [[Inspector role]] is an example of a role assigned in the system context. The [[Forum moderator role]] is an example of a role assigned in the module context. The [[Parent role]] is an example of a role assigned in the user context.

==Assigning a role==

[[Image:Roles Assign Student.JPG|thumb|Assigning users the role of student i.e. enrolling them on the course]]"Student", "Teacher", "Course Creator" are some of the predefined roles that come with Moodle. The site administrator may have created additional roles.
To assign a role:
#Choose the type of role you wish to assign. For example, if we wanted to assign a Student role to Martin, we'd choose "Student" from the list of roles.
#Once you have chosen a role, two lists appear: a list of users who currently have that role (Student Demo in the example), and a list of users who don't. We can select Martin in the second list, and use the left-facing arrow button to add Martin to the list of Students. Multiple users may be selected by holding down the Apple or Ctrl key whilst clicking on the users' names.

Removing someone from a role is done by moving the user from the left column to the right.

==Hidden assignments==

To hide which role a user is assigned to, click the Hidden assignments check box before assigning the role to the user. This feature is useful for example if you don't want everyone with teacher rights listed in the course description. This feature is also very useful for hiding system wide roles from everyone else on the site.

Note: The role assignment is not hidden from admins or teachers i.e. users with the [[Capabilities/moodle/role:viewhiddenassigns|viewhiddenassigns capability]].

==Enabling teachers to assign the role of teacher==

By default, teachers are only allowed to assign the roles of non-editing teacher, student and guest. To enable teachers to assign the role of teacher:

#Access ''Administration > Users > Permissions > Define roles''.
#Click the tab "Allow role assignments".
#Click the checkbox where the teacher row and column intersect.
#Click the "Save changes" button.

==Beware of assignments that don't make sense==

There are many role assignments that do not make sense as the underlying functionality does not exist. Just because you give someone the "right" to do something does not guarantee that the interface or facility actually exists within the context that you have assigned that right. For example, you can assign a user the right to create new categories in the category context, however there is no interface within Moodle to do that (category creation is only available at the system level).

Note: Users should only be assigned the role of [[Administrator role|administrator]] (i.e. a role with the capability [[Capabilities/moodle/site:doanything|moodle/site:doanything]] set to allow) in the system context. Users should only be assigned the role of [[Course creator role|course creator]] in the system or a course category context.

==Multiple assignments==

A significant part of the roles infrastructure is the ability to assign a user into multiple roles (at the same time). The capabilities of each role are merged to produce the effective set of capabilities. In particular it is perfectly possible for a user to be both a Teacher and Student in the same course. This differs from the behavior of Moodle prior to the introduction of roles. You should be careful to ensure that if you change a user's role that you remove them from any other roles as required as this will no longer be done automatically.

==System roles==

Roles assigned in the site (1.7) or system context (1.8 onwards) are called system roles and apply across the entire site, including the front page. For example, a user assigned the system role of teacher will have this role in every course on the site.

In many sites only admins and course creators will be assigned system roles.

The [[Blogger role]] is an example of a system role.

==Front page roles==

You can assign roles and set up role overrides for your front page in exactly the same way as for a course.

There are various ways of enabling logged-in users to participate in front page activities, depending on your Moodle version. See the [[Roles FAQ]] for details.

==Assigning a role for a front page activity==

In versions of Moodle prior to 1.9.4, only users who are assigned front page roles appear in the list of potential users when assigning a role for a front page activity.

To assign a user a role for a front page activity:
# Assign the user a front page role, such as student, in ''Administration > Front Page > Front Page roles''.
# Click the "Locally assigned roles" tab in editing activity page for the front page activity.
# Choose the type of role you wish to assign.
# Use the left-facing arrow button to add a particular user to the list of users with the role.

If a user is unassigned from a front page role AFTER being assigned a role for a front page activity, they remain assigned the role for the front page activity.

==See also==
*[[Manage roles]] - for administrators
*[[Useful things a teacher can do with roles]]

Using Moodle forum discussions:
*[http://moodle.org/mod/forum/discuss.php?d=59900 Discrepancies between Assign Roles lists and Participants list]
*[http://moodle.org/mod/forum/discuss.php?d=66782 What happens if a user has multiple roles in a course?]

[[Category:Teacher]]
[[Category:Roles]]

[[cs:Přidělení rolí]]
[[de:Rollen zuweisen]]
[[es:Asignar_roles]]
[[eu:Rolak_esleitu]]
[[fr:Attribuer des rôles]]
[[ja:ロールの割り当て]]
[[ru:Назначение ролей]]

CVS for Administrators

2011-02-02T09:21:47Z

Poltawski: The CLEO/LUNS mirror is being retired

The [http://cvs.moodle.org/ CVS archive] contains all the source code for Moodle. You can use a CVS program to extract versions ranging from the most stable release to the most cutting-edge development version. CVS can be an extremely convenient way of maintaining a Moodle server.

[[Image:Cvstree.png|CVS tree]]

Developers may have selective write access to the Moodle CVS archive (see [[CVS for Developers]] for details about how to do this). However, most people only need read-only access, so they can just connect to one of the mirrors using '''anonymous CVS''' as described below. There can however currently be a delay of up to 1 hour between the time a developer commits changes to developer CVS and the time it becomes available on anonymous CVS.

==CVS Servers==

Please choose the closest CVS mirror server to you from this list:

{| border="1" cellpadding="4" cellspacing="0"
|'''Country'''
|'''Server'''
|'''Provided by'''
|-
|EU
|'''eu.cvs.moodle.org'''
|[http://www.open.ac.uk/ The Open University] In case of trouble, contact [mailto:r.t.c.norfor@open.ac.uk Rod Norfor] or [mailto:d.a.woolhead@open.ac.uk Derek Woolhead]
|-
|ES
|'''es.cvs.moodle.org'''
|[http://www.mondragon.edu/ Mondragon Unibertsitatea] In case of trouble, contact [mailto:iarenuno@eteo.mondragon.edu iarenuno@eteo.mondragon.edu] or [mailto:iarenaza@escomposlinux.org iarenaza@escomposlinux.org]
|-
|UK
|'''uk.cvs.moodle.org'''
|[http://www.open.ac.uk/ The Open University] In case of trouble, contact [mailto:r.t.c.norfor@open.ac.uk Rod Norfor] or [mailto:d.a.woolhead@open.ac.uk Derek Woolhead]
|-
|US
|'''us.cvs.moodle.org'''
|San Francisco State University, Academic Technology ([http://www.sfsu.edu/ SFSU]). In case of trouble, contact [mailto:ilearn@sfsu.edu iLearn support]
|-
|US
|'''us2.cvs.moodle.org'''
|[http://www.contractorsinstitute.com The Contractors Institute] pserver and viewvc. In case of trouble contact [mailto:cvs@contractorsinstitute.com network support].
|}

Replace the SERVER.cvs.moodle.org in the instructions below with the server you chose above!

For up-to-date alerts about planned or unplanned outages on any of these servers subscribe to the [http://lists.moodle.org/info/outages Moodle Outage mailing list]. See [http://moodle.org/stats/network.php moodle.org/stats/network.php] for server availability.

(If you would like to contribute to the project by running a mirror, please see [[How to set up a CVS mirror]])

==Moodle versions and CVS branches==

CVS stores every version of Moodle there has ever been. Versions are organised into branches as in the diagram at the top of this page. There is one branch for each series of stable releases, so the 1.9.x releases all come from the MOODLE_19_STABLE branch.

Along that branch, each actual release is marked with a tag. For example the Moodle 1.9 release is tagged MOODLE_19, and the 1.9.1 release is MOODLE_191. The latest 1.9.x+ weekly build is always tagged MOODLE_19_WEEKLY.

The latest development version is what all the stable branches branch away from. It is sometimes called HEAD or TRUNK. At the moment (mid 2009) this is the development version of Moodle 2.0, but around the time we get to the Moodle 2.0 beta release we will create the MOODLE_20_STABLE branch, and HEAD will become 2.1 dev.

As explained below you when you do a CVS checkout, you choose which version you want.

==Installing and maintaining Moodle via CVS==

===From a Unix computer===

To connect and login for the first time to the CVS server, you can use this command (remember to replace '''SERVER.cvs.moodle.org''' in the instructions below with the mirror server you chose above):

cvs -d:pserver:anonymous@SERVER.cvs.moodle.org:/cvsroot/moodle login

There is no password - when asked for one, just hit Enter.

To checkout (download) the entire Moodle code for the first time, use this command to get the latest WEEKLY version (generally the latest, most bug free version):

cvs -z3 -d:pserver:anonymous@SERVER.cvs.moodle.org:/cvsroot/moodle co -P -r MOODLE_19_WEEKLY moodle

Or the latest development version - sometimes called HEAD - (not for production use):

cvs -z3 -d:pserver:anonymous@SERVER.cvs.moodle.org:/cvsroot/moodle co -P moodle

Or the modules in Contrib

cvs -z3 -d:pserver:anonymous@SERVER.cvs.moodle.org:/cvsroot/moodle co contrib

Later, to update your local copy of Moodle to the current version in CVS you just need to go into your local Moodle directory and type:

cvs update -dP

To update your local copy of Moodle to a new version (e.g. from 1.8+ to 1.9), go into your local Moodle directory and type:

cvs update -dP -r MOODLE_19_STABLE

To update your local copy of Moodle to a version from a specific date (e.g. 4th February 2009), go into your local Moodle directory and type:

cvs -q update -dP -r MOODLE_19_STABLE -D "4 Feb 2009"

To update your local copy and to save the log of the process, use the following command instead the previous one:

cvs update -dP -r MOODLE_19_STABLE | tee upgrade.log

Then look at the upgrade.log, notably look for lines starting with "C" (conflict):

grep '^C' upgrade.log

Conflicts may appear in case you have manually modified your source files. You have to resolve conflicts before using the site. See [[CVS for Developers]] for more details.

===Changing the directory name===

By default, the CVS checkout creates a directory on your webserver called 'moodle'. If you want your Moodle installation in a different directory, you can change the name of the directory that it will checkout the files to, by typing the following. This would download the MOODLE_19_STABLE branch into a directory called "mydirectory" (-d mydirectory).

cvs -z3 -d:pserver:anonymous@SERVER.cvs.moodle.org:/cvsroot/moodle co -P '''-d mydirectory''' -r MOODLE_19_STABLE moodle

Or the latest development version to a directory called 'moodle-dev':

cvs -z3 -d:pserver:anonymous@SERVER.cvs.moodle.org:/cvsroot/moodle co -P '''-d moodle-dev''' moodle

You can also change the name of the directory after the files are downloaded, and before you go through the Moodle install process. If you change the name of the directory before install, it will not affect anything during the install or during a CVS update. If you change the name of the directory after an install, you will need to change the config.php to reflect the name change ([[Moodle_migration#Migrating_a_complete_Moodle_site|guidance here]]). It won't affect the CVS update though.

===Change directory owner===

Depending on your webserver setup, you may well need to change the owner of the directory to the webserver user. Follow this step if you get permissions error when you try to access the page. For apache:

chown -R www-data:www-data moodle

===From a Windows computer===

To get started with a fresh copy of Moodle, follow the following steps (remember to replace '''SERVER.cvs.moodle.org''' in the instructions below with the mirror server you chose above):[[Image:CVS moodle settings for tortoise CVS.jpg|thumb|Tortoise CVS Screen capture]]
[[Image:Ecran cvs.jpg|thumb|Tortoise CVS (real name) Screen capture]]
# Get TortoiseCVS from [http://www.tortoisecvs.org/ tortoisecvs.org] and install it, then reboot.
# Find or create a new folder somewhere where you want Moodle to be downloaded to.
# Right-mouse-click that folder and choose "CVS Checkout" from the menu. You should see a dialog box.
# Copy this text into the CVSROOT field: <code>:pserver:anonymous@SERVER.cvs.moodle.org:/cvsroot/moodle</code>
#* NOTE - replace "SERVER" with "eu", "es", "uk" or "us" depending on your location.
# Under the "Module" field, type "moodle" to get moodle. (Other options here include"contrib" to get the contrib directory of hacks and addons, or "mysql" to get the optional MySQL Admin module).
#* For the latest STABLE version, click on the "Revision" tab and then check the radio button labelled "Choose branch or tag". From the drop-down menu select MOODLE_18_STABLE.
#* If you don't see the very latest version in the long drop-down list under Branch or tag name, click the Update List button next to it and wait for the list to be updated.
#* For the latest UNSTABLE development version, the radio-button "Use HEAD branch" in the Revision tab should be checked.
# Press the button: "OK" and everything should be downloaded.

Later, to update your local copy of Moodle to the current version in CVS, just right-mouse-click the folder and choose "CVS Update".

Note that the enclosing moodle folder is self-contained - you can move it anywhere you like or even rename it.

'''NOTE.-''' Admins with a developer account on cvs.moodle.org can connect with their account name, see attached screen shot.

===From a Mac OS X computer===
You will find useful informations about CVS and Mac OS X in the documentation for the complete installation package Moodle4Mac and for the Mac OS X Server installation.

Please read [[Complete_Install_Packages_for_Mac_OS_X#How_To_Update_Your_Moodle4Mac | How to update your Moodle4Mac]] or [[Step_by_Step_Installation_on_a_Mac_OS_X_Server#How_to_install_and_update_Moodle_via_CVS | How to install and to update Moodle via CVS]]. It works fine with the Moodle CVS servers.

===Troubleshooting===

If you see something like this, make sure that there is not some firewall blocking the port (it's 2401):

$ cvs -d:pserver:anonymous@us.cvs.moodle.org:/cvsroot/moodle login
Logging in to :pserver:anonymous@us.cvs.moodle.org:2401/cvsroot/moodle
CVS password:
cvs [login aborted]: connect to us.cvs.moodle.org(130.212.64.111):2401 failed: Connection timed out

==Switching to a new CVS server==

If you were ''already'' using CVS and want to switch to a different server, you'll probably need to make a small change so that the control files in your working copy will point to the new mirrors.

===Switching to a new server on Unix===

Use a shell command like this to change existing installations to point to the new mirror (UK mirror used in this example):

'''find . -type f -name Root -print0 | xargs -0 perl -pi -e 's/\@moodle\.cvs\.sourceforge\.net/\@uk\.cvs\.moodle\.org/''''

It can be run from /home, say, to fix multiple sites at once.

===Switching to a new server with TortoiseCVS===

If you were ''already'' using Tortoise CVS on Windows it's tricky, because Tortoise doesn't have any interface for changing the server. http://www.tortoisecvs.org/faq.html#changecvsroot explains it. But basically,

1) Install WinCVS and launch it.
2) Navigate to and select your Moodle folder.
3) Choose 'Macros'->CVS->Change Root from the menu.
4) Accept (or change) the default for the 'old' server.
5) Type the new server name. OK!

It takes a few seconds to go through all of the '''cvs''' folders and update the '''root''' files.

By the way, if you don't want to install WinCVS, another way of doing this is to uninstall your TortoiseCVS client on Windows, then do a regedit to clean up all the tortoisecvs related entries (might not be necessary), then reinstall TortoiseCVS client again (a good reason to upgrade to the most recent version of TortoiseCVS!). I have tested this and it cleared up the original setting of the original anonymous CVS server setting.

==See also==

*[[Talk:CVS for Administrators]]
*[[Development:CVS_for_developers|CVS for developers]]
*[[Development:Setting up Eclipse]] for step by step instructions for setting up the [http://www.eclipse.org/ Eclipse IDE] for Moodle development, which including how to do the necessary CVS operations
*[[Development:Setting up Netbeans]] step by step instructions for those who prefer the [http://netbeans.org/ NetBeans IDE]. NetBeans comes with integrated CVS support.
* [[Development:Tracking Moodle CVS with git]]
Using Moodle forum discussions:
*[http://moodle.org/mod/forum/discuss.php?d=26731&parent=125858 Using cvs]
*[http://moodle.org/mod/forum/discuss.php?d=91891 CVS Updating of 3rd-Party Plug-ins in the Moodle folder itself]
*[http://moodle.org/mod/forum/discuss.php?d=108196 simple question for cvs]

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

[[de:CVS für Administratoren]]
[[fr:CVS pour administrateurs]]
[[ja:管理者用CVS]]
[[ru:CVS для администраторов]]

Moodle 2.0 release notes

2010-11-23T09:48:52Z

Poltawski: Corrected my email domain

{{Work_in_progress}}

Expected final release date: '''November, 2010''' (if testing goes well)

Moodle 2.0 contains a lot of large new features, some completely rewritten features, and hundreds of bug fixes. For full details (more than you probably want!), see [http://tracker.moodle.org/browse/MDL/fixforversion/10122 the full list of fixed issues in 2.0].

This page is a summary of the major things to look for.

==Major new features==

===[[Community hub|Community hubs]]===

* Anybody can set up a Community hub, which is a directory of courses for public use or for private communities. The code is implemented as separate GPL plugin for Moodle.
* Sites can register to any Community hub (instead of just moodle.org)
* Teachers on registered sites can publish their full courses to Community hubs, for download
* Teachers on registered sites can also advertise their courses on Community hubs, for people to join
* Teachers on any site can search all public Community hubs and download courses as templates for their own courses
* Users on any Moodle site can also search Community hubs for courses (and communities of practice) to participate in. Initially we are encouraging ''''communities of teaching practice'''' but any sort of course can be listed.

===[[Repositories|Repository support]]===

* Moodle now supports integration with external repositories of content, making it really simple to bring documents and media into Moodle via an AJAX interface that looks like a standard '''Open''' dialogue in desktop applications.
* Initial plugins in 2.0 include: Alfresco, Amazon S3, Box.net, File system on Server, Flickr, Google Docs, Mahara, MERLOT, Picasa, Recent Files, Remote Moodle sites, WebDAV servers, Wikimedia, Youtube. These are simple to develop, so many more are expected.
* You can also import files from your desktop or by specifying a URL.

===[[Portfolios|Portfolio support]]===

* Modules can now export their data to external systems, particularly useful for portfolios where snapshots of forums, assignments and other things in Moodle are useful to record in a journal or a portfolio of evidence
* Different formats are supported (currently LEAP2A, HTML, Images and Text, but others like PDF can be added)
* Initial plugins in 2.0 include: Box.net, Flickr, Google Docs, '''Mahara''' and Picasa.

===[[Completion]]===

* Teachers can now specify conditions that define when any '''activity''' is seen as completed by a student. For example, when a certain number of posts have been made, or a grade has been reached, or a choice has been made.
* Teachers can now specify conditions that define with any '''course''' is seen as completed by a student. Conditions include activity completion, but could also be by grade, date or a number of other criteria.
* Teachers and students can see reports that show the progress of any user within a course, or through a series of courses.

===[[Conditional activities]]===

* Access to activities can be restricted based on certain criteria, such as dates, grade obtained, or the completion of another activity.
* These can be chained together to enable progressive disclosure of the course content, if that is desired.

===[[Cohorts]]===
* Also known as "Site-wide groups", these are site-wide collections of users that can be enrolled into courses in one action, either manually or synchronised automatically

===[[Web Services|Web services support]]===
* Support for standards-based web services across the entire Moodle code base, allowing the admin to expose particular functions of Moodle for use by:
** Administrative systems such as HR or SIS applications
** Mobile clients
* Framework contains a very high-level of security with a detailed token system and complete control over the range of functions exposed
* All defined functions are automatically available via:
** XML-RPC
** AMF (Flash)
** REST
** SOAP (PHP)

===[[IMS Common Cartridge import|IMS Common Cartridge]]===
* Moodle can now import courses in IMS Common Cartridge format (commonly used by publishers)

===New blocks===
* [[Comments block]] - like a shoutbox, allows comments to be added to any page. Great for student feedback.
* [[My private files block]] - allows easy access to one's private file repository in Moodle (with quota support)
* [[Community block]] - keeps track of external courses one is interested in
* [[Course completion status block]] - reports on the completion status of your courses

===[[Plagiarism Prevention|Plagiarism prevention]]===

* Moodle supports integration with plagiarism prevention tools such as Turnitin

==Major improvements to existing core features==

===[[Backup 2.0|Backup and restore]]===

* Completely rewritten Backup/Restore framework, no longer bound by memory (can work with '''any size course''').
* Completely new backup format.
* Improved interface.
* Backup can be made of whole courses, but also specific sections or activities.

===[[Blocks 2.0|Blocks]]===
* Blocks are now consistently implemented on every page in Moodle
* No longer any limit to the block regions (in addition to left and right, put them at the top, center or bottom of pages)
* Any block can be made sticky (appears in all the contexts below, eg throughout a course).
* Blocks can be "docked" on the side of the screen (if the theme supports it)

===[[Blogs 2.0|Blogs]]===
* Support for comments on each blog entry
* Removal of group-level and course-level blogs (these are converted into forums on upgrade)
* Support for external blog feeds (synchronised to Moodle blog)

===[[Comments 2.0|Comments]]===
* User comments (Glossaries, Databases, Blogs, etc) are now all consistently handled and displayed throughout Moodle, using AJAX if available

===[[Enrolments 2.0|Enrolment plugins]]===
* Major improvements in the handling of guests and guest accounts
* Support for multiple forms of enrolment at the same time
* More detailed control over enrolment in courses

===[[File handling 2.0|File handling]]===

* Full support for Unicode file names on all operating systems.
* Metadata about each file (author, date, license, etc) and what the file is used for are stored in the database.
* Duplicate files (for example, a large video file use in two different courses) are only stored once, saving disk space.
* Files are no longer just "uploaded to the course". Files are connected to the particular bit of Moodle content that uses them. (For example, a file may belong to a file resource, a forum post or a wiki page). Access to these files is then controlled by the same rules as as that bit of Moodle, increasing security.

===[[Filters 2.0]]===

* In the past, you had to use the same filters everywhere in your Moodle site, and this could only be changed by admins.
* Now, you can have different filters in different courses, activities or categories.
* For example, you could turn on the LaTeX filter just for courses in the Maths and Physics categories.
* Or you could turn off glossary linking in the end of course exam.

===[[HTML editor 2.0|HTML editor]]===
* New editor based on TinyMCE
* Works on more browsers
* Resizable editing area
* Cleaner XHTML output
* Full integration with configured external repositories to import and embed media into text

===[[Messaging 2.0|Messaging]]===
* All email sent by Moodle is now treated as a message
* A message overview panel allows users to control how messages are sent to them
* Initial message output plugins in Moodle 2.0 include: Email, Jabber and Popups

===[[My Moodle 2.0|My Moodle page]]===
* More customisable My Moodle page with new blocks for showing relevant information
* Admin can design (and optionally force) site-wide layouts for My Moodle
* My Moodle page given more prominence as the main "home page" for users

===[[Navigation 2.0|Navigation]]===
* Standard "Navigation" block on every page showing contextual links, while allowing you to jump elsewhere quickly
* Standard "Settings" blocks on every page shows contextual settings as well as settings for anything else you have permissions for

===[[Ratings 2.0|Ratings]]===
* User ratings (Glossaries, Databases, Forums, etc) are now all consistently handled and displayed throughout Moodle, using AJAX if available
* Aggregation of using ratings into activity grades is now standardised in all activities

===[[Roles 2.0|Roles and permissions]]===
* Improved and simplified AJAX interfaces for defining and assigning roles
* Improved and simplified interfaces for tweaking permissions in any given context
* New "Archetypes" concept replacing the "Legacy roles" concept.
* New archetype "manager" to define the role of most people with system-wide editing rights, separate from "admin" role.

===[[RSS feeds 2.0|RSS feeds]]===
* All RSS feeds are now secured using a random per-user token in the URL
* Tokens can be updated by the user at any time (if they suspect a feed URL has been compromised)
* RSS feeds are now more accurate (eg they support forums with separate groups), and are generated efficiently whenever required

===[[Development:Themes 2.0|Themes]]===
* Many new themes in the core distribution - see [[Theme credits]] for a list
* All HTML and JS ouput is now far more efficient (server-side caching) and consistent (tableless layout, new CSS, YUI Framework)
* Themes can change the HTML of the page if they wish
* Core support for custom menus in all themes (for example at the top of the page)

===[[Translation 2.0|Translation system]]===
* [http://lang.moodle.org/ New web portal] to make it easer for groups to collaborate on translating Moodle, and to keep their translations up-to-date.
* More efficient [[Development:Languages/AMOS|storage format for language strings]] should slightly improve performance.

===User profile pages===
* Site-wide user profile page can be customised by users with blocks, news, feeds and so on
* Course-specific user profile pages show course blocks and standard profile information, plus information for teachers of that course

==Major improvements to activity modules==

===Lesson===
* Refactored internal code
* Forms are now standard Moodle forms

===Quiz module and question bank===

* [[Development:quiz_navigation|Quiz navigation improvements for students]]
* [[Development:Flagging_questions_during_a_quiz_attempt|Flagging questions during a quiz attempt]]
* [[Development:Quiz_report_enhancements|Quiz report enhancements]] - Major improvements to the quiz reports, especially regrading and item analysis
* [[Development:Quiz_report_statistics|Quiz report statistics]] - A brief guide
* [[Development:Quiz_UI_redesign|Quiz editing interface improvements]]
* Different settings (open/close date, number of attempts, password, time limit) for each group or student (MDL-16478)
* [[Development:Administration page for question types|Administration page for question types]]
* [[Development:Moodle 2.0 question bank improvements|Question tagging and improved searching in the question bank]]
* MDL-8648 Essay questions can now be randomised by random questions

===Resource===
* All the resource types have been refactored into real modules, and cleaned up
** File - for displaying a file, possibly with supporting files (like a HTML mini-site)
** Folder - for displaying a collection of documents
** URL - for displaying a page with a given URL
** Page - for a single page, edited online using the HTML editor
** IMS - for showing a regular IMS content package
* Better XHTML-compliant support for frames, iframes and embedding in all these modules

===SCORM===

* New [[SCORM module]] settings - display attempt status, display course structure, force completed, force new attempt, lock after final attempt - allowing the behaviour dictated to the SCORM object by the authoring package to be changed MDL-11501
* New reporting interface including sortable/collapsible table with group select box and ability to download in Excel, ODS and text format MDL-21555
* New SCORM player UI with better navigation, improved performance and better handling of stage size MDL-22951

===[[Wiki module 2.0|Wiki]]===
* Completely re-written from scratch, based on NWIki from UPC
* Support for Mediawiki-style syntax, as well as Creole
* Interface improvements

===[[Workshop module 2.0|Workshop]]===

* Completely rewritten from scratch
* Vastly improved interface for managing stages and users

==System requirements==

Since Moodle 2.0 is such a major release, we are allowing ourselves some increases in the requirements.

* PHP must be 5.2.8 or later (it was released 08-Dec-2008)
* Databases should be one of the following:
** MySQL 5.0.25 or later (InnoDB storage engine highly recommended)
** PostgreSQL 8.3 or later
** Oracle 10.2 or later
** MS SQL 2005 or later
* Any standards-supporting browser from the past few years, for example:
** Firefox 3 or later
** Safari 3 or later
** Google Chrome 4 or later
** Opera 9 or later
** MS Internet Explorer 7 or later (Even [http://googleenterprise.blogspot.com/2010/01/modern-browsers-for-modern-applications.html Google don't support IE6 any more])
** etc

==Upgrading==

When upgrading to Moodle 2.0, you must have Moodle 1.9 or later. if you are using an earlier version of Moodle (eg 1.8.x) then you need to upgrade to Moodle 1.9.x first. We advise that you test the upgrade first on a COPY of your production site, to make sure it works as you expect.

For further information, see [[Upgrading to Moodle 2.0]].

==For developers: API changes==

See [[Development:Migrating_contrib_code_to_2.0]]

* [[Development:Plugin system changes in Moodle 2.0]] - all the different types of plugin are now handles more consistently when it comes to installation and upgrading, capabilities, events, and so on.
* [[Development:DB_layer_2.0_migration_docs|Database layer changes]] - you will need to update your code.
* [[Development:Using_the_file_API|File handling changes]] - you will need to update your code.
* [[Development:Migrating your code code to the 2.0 rendering API|Rendering layer changes]] - should be mostly backwards compatible, but you are advised to upgrade your code.
* Require capability used to do an automatic require_login. It no longer does so. All pages must explicitly call require_login if they need it. MDL-19882
* [[Development:Moodle_2.0_question_type_API_changes|Changes to the question type API]]
* MNet has been refactored and tidied up - related third party code needs to be checked
* Changes and improvements to the [[Development:Local_customisation|Local customisation system]].
* Javascript
* YUI
* custom profile fields values are loaded into $USER->profile array instead of directly into $USER object

==Credits==

These people made check-ins to Moodle 2.0 code. Thanks to all of them, of course. Some of these people represent a team of people who actually worked on the code.

Robert Allerstorfer <anet.at>
Inaki Arenaza <eteo.mondragon.edu>
Aaron Barnes <catalyst.net.nz>
Gordon Bateson <kanazawa-gu.ac.jp>
John Beedell <open.ac.uk>
Aparup Banerjee <moodle.com>
Andrea Bicciolo <mtouch.it>
Anthony Borrow <jesuits.net>
Peter Bulmer <catalyst.net.nz>
Dongsheng Cai <moodle.com>
Matt Clarkson <catalyst.net.nz>
Nicolas Connault <moodle.com>
Andrew Davis <moodle.com>
Gustav Delius <york.ac.uk>
Martin Dougiamas <moodle.com>
Shane Elliott <shane@pukunui.com>
Ethem Evlice
Helen Foster <moodle.com>
Nicholas Freear <open.ac.uk>
Valery Fremaux
Dariem Garces
Andreas Grabs <grabs-edv.de>
Jenny Gray <open.ac.uk>
Jonathan Harker <catalyst.net.nz>
Piers Harding <catalyst.net.nz>
Lukas Haemmerle <switch.ch>
Sam Hemelryk <moodle.com>
Ashley Holman <netspot.com.au>
Luke Hudson <catalyst.net.nz>
Tim Hunt <open.ac.uk>
Urs Hunkler <unodo.de>
Mike Churchward <oktech.ca>
Wen Hao Chuang <gmail.com>
Samuli Karevaara <lamk.fi>
Michael Ketcham <microsoft.com>
Eloy Lafuente <moodle.com>
Martin Langhoff <catalyst.net.nz>
Penny Leach <liip.ch>
Patrick Malley <newschoollearning.com>
Dan Marsden <catalyst.net.nz>
Francois Marier <catalyst.net.nz>
Sam Marshall <open.ac.uk>
Donal McMullan <catalyst.net.nz>
Eric Merrill <oakland.edu>
Howard Miller <e-learndesign.co.uk>
Gareth Morgan <open.ac.uk>
Jerome Mouneyrac <moodle.com>
David Mudrak <moodle.com>
Jonathan Newman <catalyst.net.nz>
Mark Nielsen <moodlerooms.com>
Matt Oquist <majen.net>
Mathieu Petit-Clair <moodle.com>
Pierre Pichet <uqam.ca>
Roberto Pinna <mfn.unipmn.it>
Jordi Piguillem <upc.edu.es>
Dan Poltawski <luns.net.uk>
Jamie Pratt <jamiep.org>
Joseph Rezeau <rezeau.org>
Shamim Rezaie <rezaie.info>
Luis Rodrigues
Olli Savolainen
Petr Skoda <moodle.com>
John Stabinger
Rossiani Wijaya <moodle.com>
Derek Woolhead <open.ac.uk>
Mitsuhiro Yoshida <mitstek.com>
Yu Zhang <moodle.com>

==See also==

* [[Moodle 2.0 Preview 1 release notes]] - May 4, 2010
* [[Moodle 2.0 Preview 2 release notes]] - May 17, 2010
* [[Moodle 2.0 Preview 3 release notes]] - May 31, 2010
* [[Moodle 2.0 Preview 4 release notes]] - June 30, 2010
* [[Moodle 2.0 Release Candidate 1 release notes]] - September 21, 2010

*[[Moodle 1.9 release notes]]
*[[QA testing]]

[[Category:Release notes]]
[[Category:Moodle 2.0]]

[[fr:Notes de mise à jour de Moodle 2.0]]
[[es:Notas de Moodle 2.0]]

Installations 30000 plus

2010-10-19T21:34:25Z

Poltawski: updated our moodle stats

{{Template:Large Installations}}

==Austria==

* Federal Ministry of Education - [http://www.eduhi.at/ education highway]: [http://www.edumoodle.at Free Moodle for Austrian schools.]
(Nov/2009)
- 26.000 courses
- 230.000 users
- 1.711 schools
- 2 hosting centers, about 15 servers, shared moodle sources

==Brazil==

* [https://moodle.eadesaf.serpro.gov.br Escola de Administração Fazendária - ESAF]
Hospeda mais de 1.770 cursos, com 69.883 Estudantes e 1.869 Tutores (em 01/08/2010), atendendo a vários segmentos do serviço público do Brasil.

* [http://aprender.unb.br Universidade de Brasília] - 66,587 users (04/30/2009)
* [http://ead.mackenzie.br/mackenzievirtual/ Universidade Presbiteriana Mackenzie] - 43,237 users (25/06/2009)

==Italy==

* [http://elearning.uniroma1.it/ InfoSapienza - University of Rome La Sapienza] InfoSapienza's Moodle hosts more than 700 courses for about 48.000 students from about 25 faculties, ranging from enginering scientific courses to literature and medicine. (April, 9th 2009)

==Spain==

* [http://www.ehu.es Universidad del Pais Vasco - Euskal Herriko Unibertsitatea (UPV/EHU)]: . 34.000 users and 1.650 teachers (different) in aprox. 3.650 courses. Our University have 50.000 students, 3.500 teachers. We started with Moodle 1.6 (four years ago) as a test pilot project for a small number of courses. Currently we are using version 1.9 (since 2009, February) with LDAP authentication.

==Taiwan==

* [http://moodle.mcu.edu.tw Ming Chuan University]
- More then 63,000 users
- 33,000 users login in one day(Max)

==United Kingdom==

* The UK's [http://www.open.ac.uk/ Open University], a world leading institution and innovator in distance learning based in Milton Keynes, Buckinghamshire, England is well on the way to creating the world's largest Moodle installation in a £5 Million project. It is expected to host nearly 200,000 students. [http://www3.open.ac.uk/media/fullstory.aspx?id=7354 OU's News item]

* While not a single moodle, [http://www.luns.net.uk LUNS ltd] host one of the largest clusters of Moodle installs for [http://www.cleo.net.uk/ CLEO] , with over 260,000 registered users across over 950 individual moodle installs provided to every school in Cumbria and Lancashire. Approximately 65,000 users have been active in the last month as of Jan 09.

==United States==

* [http://www.sfsu.edu San Francisco State University (SFSU)] - 89,543 users (02/07/2008). Among these 89K users, about 35,430 users are considered as currently active.

* [http://www.umn.edu/moodle University of Minnesota (UofM)] - 60,863 user accounts with around 3,000 course sites on production server. 20,994 users enrolled into academic course sites in Spring 2009. More stats: http://umn.edu/moodle/about/statistics.html

* [http://moodle.pcsb.org Pinellas County Schools] - 56,398 registered users who have logged in and created profiles. Over 5,000 course sites that are used for everything from K12 virtual instruction to teacher professional development.

Broken/id:10689

2010-03-08T23:50:02Z

Poltawski: New page: The goals specified seem to cover exactly what I think the use case for 'global groups' are :) --~~~~

The goals specified seem to cover exactly what I think the use case for 'global groups' are :) --[[User:Dan Poltawski|Dan Poltawski]] 23:50, 8 March 2010 (UTC)

Czech Hackfest 2009

2009-12-05T10:28:06Z

Poltawski: added paintweb to 'agenda'

== See also ==

* [http://dev.moodle.org/course/view.php?id=5 Moodle Hackfest 2009] online course
* Tag #moodledev09

== Programme ==

; Saturday 5th December 2009 :

* Meet each others in Prague (some arrive, some may be there already)
* Settle down in a hotel - Andel's hotel - [http://www.andelshotel.com], rooms booked
* Explore Prague (Castle, Chrles bridge, old town square, etc.)
* Social beer event

; Sunday 6th December 2009 :
* Leaving Prague at 10:30 together by a rented micro-bus (about 120 mins)
* Lunch at [http://www.jested.cz Jested, Liberec] or in Liberec.
* Moving to the mountains (by bus or car or foot ;-), according to snow conditions)
* Accommodating at [http://www.dudovi.cz/jizerka/eng/ubytovani.htm Jizerka] ( [http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=jizerka&sll=50.82524,15.428925&sspn=0.298851,0.467606&ie=UTF8&t=h&hq=&hnear=Kořenov-Jizerka,+Czech+Republic&ll=50.822313,15.329361&spn=0.149435,0.233803&z=13 Google Maps] )

; Monday 7th December 2009
* Moodle 2.0 release planning
* Triage of remaining bugs (assign developers, priorities)
* Bug sprint

; Tuesday 8th December 2009
* Moodle 2.x planning
* Creating detailed roadmap for all modules based on tracker

; Wednesday 9th December 2009
* Moodle 3.0 brainstorming and planning
* Moodle 2.0 bugs

; Thursday 10th December 2009
* Moodle 2.0 bugs
* Skiiing?

; Friday 11th December 2009
* moving back to Prague on Friday
* more Prague sightseeing
* - Andel's hotel - [http://www.andelshotel.com], rooms booked
* official end of hackfest

== Things to discuss ==

* [[Development:Languages]]
* Synchronising grades between Gradebook and modules like quiz that automatically compute a grade. What happens if the teacher edits in the gradebook so the grade becomes locked, then the student re-attempts the quiz and gets another grade?
* Decide about the PARAM_XXX cleaners, where they can be used and other types of validation (just simple types, allow DB access too, only use them for param cleaning, PARAM_XXX as regexp constants, PARAM_XXX extensible via /local stuff). But in any case, must be decided and documented once and for all.
* Talk about adding class="moodletarget_xxxx" to links we were sending to new page via target="_xxxx" (non XHTML anymore) and post-process them with JS.
* Discuss about date/time/timezones/calendars in 2.0. One initial point of reference: MDL-18375
* planned changes in themes
* major roles and enrolment changes
* future of assignment module
* performance problems
* cron processing
* large scale moodle set-ups
* webservices and integrations with 3rd party systems, CLI tools
* Integrating paintweb?

== Attendees and arrivals ==

Maximum of 16 places, so far we have (in chaotic order):

# Martin Dougiamas
# Eloy Lafuente
# Petr Skoda
# Tim Hunt
# Helen Foster
# Penny Leach
# Dan Poltawski
# David Mudrak
# Shane Elliott
# Chris Roy
# Brian King
# Daniele Cordella
# Mike Churchward
# Hubert Chathi
# Matt Oquist
# Kris Stokking

== Suggestions ==

I wanted to add some ideas of things we could talk about, and for some reason I did not want to use the talk page so I am adding them here. These are just ideas. Take them or leave them.

===What is the balance between Yack and Hack?===

That is, how much time will we be talking, and how much time writing code on our laptops?--[[User:Tim Hunt|Tim Hunt]] 09:41, 8 August 2009 (UTC)

Probably more yacking than hacking....

===Planning specific bits of the post 2.0-roadmap===

The main thing is that we keep talking about how recent released, especially 2.0, have had a lot of under the hood changes and that we really need to do some work on the actual activities themselves. I was wonder if if we should have a section of time allocated to what we consider the most important modules (or other things like the gradebook/filepicker/backup).

In order to have meaningful discussion, I suggest that in advanced of the hackfest, each participant is assigned (or volunteers for) one of those bit. They are then expected to read every open bug and feature request for that component, and spend some time following the associated forum, and come up with a summary of what the most pressing issues there seem to be. Then at the hackfest they would lead that discussion section, kicking off by explaining to the rest of us what they learned during their research.

Naturally, if we do this, I volunteer for the quiz and question bank. Of course, I already have a pretty good idea what is going on there. I guess this would probably be more work if people had to look at an area they had not thought about before, so that is not fair.--[[User:Tim Hunt|Tim Hunt]] ~10:00, 6 August 2009 (UTC)

: +1. Naturally, I volunteer for Workshop, given that the Tim's last sentence applies for my case, too. --[[User:David Mudrak|David Mudrak]] 10:51, 7 August 2009 (UTC)

===How about a work-on-2.0 day===

The aim would be that by the end of the day, we have fixed as many of the Fix-for 2.0 bugs as possible, and also have reviewed all the ones that we cannot fix immediately, so we end up with a really good, triaged bug-list of what is left to be done. By the end of the day, all the bugs should be assigned to someone who feels confident they will be able to fix it.--[[User:Tim Hunt|Tim Hunt]] 09:41, 8 August 2009 (UTC) and Dan Poltawski. We discussed this at the GBBF last night.

==='Prepared' Bug Squashing===

Basically the same as the above suggestion, but I want to emphasise some preperation beforehand so that we can get to the real unsolved issues which would benefit with us all being in the same room and discussing solutions.

With each bug we triage before the hackfest, we should try to:
* a) Link or close issues which have been fixed, or will be fixed by 2.0 (etc)
* b) Document unsolved issues which we need discussion or a plan to be fixed ('''this is most important for the hackfest itself''')
* c) Document bugs which could be fixed with a little time (at the hackfest or later)
* d) Document bugs to pester someone else about ;-)

Depending on how much time you can devote, I suggest trying these triaging views in order:
* 1) Reviewing all open bugs reported by yourself, starting oldest first.
* 2) Reviewing your assigned issues, starting with oldest first
* 3) Reviewing 'nobody' or 'imported' bugs starting with the oldest first.
etc..

There is a lot of old cruft in the tracker. Many of the issues have or will be fixed soon, so we could do a lot by just looking at our own issues and setting the status/links appropiately. For all the others, some are just without a decided solution - these would be great ones to at least think about discussing. --[[User:Dan Poltawski|Dan Poltawski]] 17:28, 15 August 2009 (UTC)

Czech Hackfest 2009

2009-11-29T22:58:20Z

Poltawski:

== See also ==

* [http://dev.moodle.org/course/view.php?id=5 Moodle Hackfest 2009] online course

== Programme ==

; Saturday 5th December 2009 :

* Meet each others in Prague (some arrive, some may be there already)
* Settle down in a hotel - probably [http://www.andelshotel.com] or [http://www.angelohotel.com] (we are discussing with them to get some sale, do not book anything yet).
* Explore Prague (Castle etc)
* Social beer event

; Sunday 6th December 2009 :
* Leaving Prague together by a rented micro-bus (about 120 mins)
* Lunch at [http://www.jested.cz Jested, Liberec].
* Moving to the mountains (by bus or car or foot ;-), according to snow conditions)
* Accommodating at [http://www.dudovi.cz/jizerka/eng/ubytovani.htm Jizerka] ( [http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=jizerka&sll=50.82524,15.428925&sspn=0.298851,0.467606&ie=UTF8&t=h&hq=&hnear=Kořenov-Jizerka,+Czech+Republic&ll=50.822313,15.329361&spn=0.149435,0.233803&z=13 Google Maps] )

; Monday 7th December 2009
* Moodle 2.0 release planning
* Triage of remaining bugs (assign developers, priorities)
* Bug sprint

; Tuesday 8th December 2009
* Moodle 2.x planning
* Creating detailed roadmap for all modules based on tracker

; Wednesday 9th December 2009
* Moodle 3.0 brainstorming and planning
* Moodle 2.0 bugs

; Thursday 10th December 2009
* Moodle 2.0 bugs
* Skiiing?

; Friday 11th December 2009
* moving back to Prague on Friday
* more Prague sightseeing
* Settle down in a hotel - probably again [http://www.andelshotel.com] or [http://www.angelohotel.com] (we are discussing with them to get some sale, do not book anything yet).
* official end of hackfest

== Things to discuss ==

* [[Development:Languages]]
* Synchronising grades between Gradebook and modules like quiz that automatically compute a grade. What happens if the teacher edits in the gradebook so the grade becomes locked, then the student re-attempts the quiz and gets another grade?

== Attendees and arrivals ==

Maximum of 16 places, so far we have (in chaotic order):

# Martin Dougiamas
# Eloy Lafuente
# Petr Skoda
# Tim Hunt
# Helen Foster
# Penny Leach
# Dan Poltawski
# David Mudrak
# Shane Elliott
# Chris Roy
# Brian King
# Daniele Cordella
# Mike Churchward
# Hubert Chathi
# Matt Oquist
# Kris Stokking

== Suggestions ==

I wanted to add some ideas of things we could talk about, and for some reason I did not want to use the talk page so I am adding them here. These are just ideas. Take them or leave them.

===What is the balance between Yack and Hack?===

That is, how much time will we be talking, and how much time writing code on our laptops?--[[User:Tim Hunt|Tim Hunt]] 09:41, 8 August 2009 (UTC)

===Planning specific bits of the post 2.0-roadmap===

The main thing is that we keep talking about how recent released, especially 2.0, have had a lot of under the hood changes and that we really need to do some work on the actual activities themselves. I was wonder if if we should have a section of time allocated to what we consider the most important modules (or other things like the gradebook/filepicker/backup).

In order to have meaningful discussion, I suggest that in advanced of the hackfest, each participant is assigned (or volunteers for) one of those bit. They are then expected to read every open bug and feature request for that component, and spend some time following the associated forum, and come up with a summary of what the most pressing issues there seem to be. Then at the hackfest they would lead that discussion section, kicking off by explaining to the rest of us what they learned during their research.

Naturally, if we do this, I volunteer for the quiz and question bank. Of course, I already have a pretty good idea what is going on there. I guess this would probably be more work if people had to look at an area they had not thought about before, so that is not fair.--[[User:Tim Hunt|Tim Hunt]] ~10:00, 6 August 2009 (UTC)

: +1. Naturally, I volunteer for Workshop, given that the Tim's last sentence applies for my case, too. --[[User:David Mudrak|David Mudrak]] 10:51, 7 August 2009 (UTC)

===How about a work-on-2.0 day===

The aim would be that by the end of the day, we have fixed as many of the Fix-for 2.0 bugs as possible, and also have reviewed all the ones that we cannot fix immediately, so we end up with a really good, triaged bug-list of what is left to be done. By the end of the day, all the bugs should be assigned to someone who feels confident they will be able to fix it.--[[User:Tim Hunt|Tim Hunt]] 09:41, 8 August 2009 (UTC) and Dan Poltawski. We discussed this at the GBBF last night.

==='Prepared' Bug Squashing===

Basically the same as the above suggestion, but I want to emphasise some preperation beforehand so that we can get to the real unsolved issues which would benefit with us all being in the same room and discussing solutions.

With each bug we triage before the hackfest, we should try to:
* a) Link or close issues which have been fixed, or will be fixed by 2.0 (etc)
* b) Document unsolved issues which we need discussion or a plan to be fixed ('''this is most important for the hackfest itself''')
* c) Document bugs which could be fixed with a little time (at the hackfest or later)
* d) Document bugs to pester someone else about ;-)

Depending on how much time you can devote, I suggest trying these triaging views in order:
* 1) Reviewing all open bugs reported by yourself, starting oldest first.
* 2) Reviewing your assigned issues, starting with oldest first
* 3) Reviewing 'nobody' or 'imported' bugs starting with the oldest first.
etc..

There is a lot of old cruft in the tracker. Many of the issues have or will be fixed soon, so we could do a lot by just looking at our own issues and setting the status/links appropiately. For all the others, some are just without a decided solution - these would be great ones to at least think about discussing. --[[User:Dan Poltawski|Dan Poltawski]] 17:28, 15 August 2009 (UTC)

Czech Hackfest 2009

2009-11-29T22:55:54Z

Poltawski: adding a google maps link because I keep wanting to link to it ;-)

Work in progress here - do not rely on this yet.

== See also ==

* [http://dev.moodle.org/course/view.php?id=5 Moodle Hackfest 2009] online course

== Programme ==

; Saturday 5th December 2009 :

* Meet each others in Prague (some arrive, some may be there already)
* Settle down in a hotel - probably [http://www.andelshotel.com] or [http://www.angelohotel.com] (we are discussing with them to get some sale, do not book anything yet).
* Explore Prague (Castle etc)
* Social beer event

; Sunday 6th December 2009 :
* Leaving Prague together by a rented micro-bus (about 120 mins)
* Lunch at [http://www.jested.cz Jested, Liberec].
* Moving to the mountains (by bus or car or foot ;-), according to snow conditions)
* Accommodating at [http://www.dudovi.cz/jizerka/eng/ubytovani.htm Jizerka] ( [http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=jizerka&sll=50.82524,15.428925&sspn=0.298851,0.467606&ie=UTF8&t=h&hq=&hnear=Kořenov-Jizerka,+Czech+Republic&ll=50.822313,15.329361&spn=0.149435,0.233803&z=13 Google Maps] )

; Monday 7th December 2009
* Moodle 2.0 release planning
* Triage of remaining bugs (assign developers, priorities)
* Bug sprint

; Tuesday 8th December 2009
* Moodle 2.x planning
* Creating detailed roadmap for all modules based on tracker

; Wednesday 9th December 2009
* Moodle 3.0 brainstorming and planning
* Moodle 2.0 bugs

; Thursday 10th December 2009
* Moodle 2.0 bugs
* Skiiing?

; Friday 11th December 2009
* moving back to Prague on Friday
* more Prague sightseeing
* Settle down in a hotel - probably again [http://www.andelshotel.com] or [http://www.angelohotel.com] (we are discussing with them to get some sale, do not book anything yet).
* official end of hackfest

== Things to discuss ==

* [[Development:Languages]]
* Synchronising grades between Gradebook and modules like quiz that automatically compute a grade. What happens if the teacher edits in the gradebook so the grade becomes locked, then the student re-attempts the quiz and gets another grade?

== Attendees and arrivals ==

Maximum of 16 places, so far we have (in chaotic order):

# Martin Dougiamas
# Eloy Lafuente
# Petr Skoda
# Tim Hunt
# Helen Foster
# Penny Leach
# Dan Poltawski
# David Mudrak
# Shane Elliott
# Chris Roy
# Brian King
# Daniele Cordella
# Mike Churchward
# Hubert Chathi
# Matt Oquist
# Kris Stokking

== Suggestions ==

I wanted to add some ideas of things we could talk about, and for some reason I did not want to use the talk page so I am adding them here. These are just ideas. Take them or leave them.

===What is the balance between Yack and Hack?===

That is, how much time will we be talking, and how much time writing code on our laptops?--[[User:Tim Hunt|Tim Hunt]] 09:41, 8 August 2009 (UTC)

===Planning specific bits of the post 2.0-roadmap===

The main thing is that we keep talking about how recent released, especially 2.0, have had a lot of under the hood changes and that we really need to do some work on the actual activities themselves. I was wonder if if we should have a section of time allocated to what we consider the most important modules (or other things like the gradebook/filepicker/backup).

In order to have meaningful discussion, I suggest that in advanced of the hackfest, each participant is assigned (or volunteers for) one of those bit. They are then expected to read every open bug and feature request for that component, and spend some time following the associated forum, and come up with a summary of what the most pressing issues there seem to be. Then at the hackfest they would lead that discussion section, kicking off by explaining to the rest of us what they learned during their research.

Naturally, if we do this, I volunteer for the quiz and question bank. Of course, I already have a pretty good idea what is going on there. I guess this would probably be more work if people had to look at an area they had not thought about before, so that is not fair.--[[User:Tim Hunt|Tim Hunt]] ~10:00, 6 August 2009 (UTC)

: +1. Naturally, I volunteer for Workshop, given that the Tim's last sentence applies for my case, too. --[[User:David Mudrak|David Mudrak]] 10:51, 7 August 2009 (UTC)

===How about a work-on-2.0 day===

The aim would be that by the end of the day, we have fixed as many of the Fix-for 2.0 bugs as possible, and also have reviewed all the ones that we cannot fix immediately, so we end up with a really good, triaged bug-list of what is left to be done. By the end of the day, all the bugs should be assigned to someone who feels confident they will be able to fix it.--[[User:Tim Hunt|Tim Hunt]] 09:41, 8 August 2009 (UTC) and Dan Poltawski. We discussed this at the GBBF last night.

==='Prepared' Bug Squashing===

Basically the same as the above suggestion, but I want to emphasise some preperation beforehand so that we can get to the real unsolved issues which would benefit with us all being in the same room and discussing solutions.

With each bug we triage before the hackfest, we should try to:
* a) Link or close issues which have been fixed, or will be fixed by 2.0 (etc)
* b) Document unsolved issues which we need discussion or a plan to be fixed ('''this is most important for the hackfest itself''')
* c) Document bugs which could be fixed with a little time (at the hackfest or later)
* d) Document bugs to pester someone else about ;-)

Depending on how much time you can devote, I suggest trying these triaging views in order:
* 1) Reviewing all open bugs reported by yourself, starting oldest first.
* 2) Reviewing your assigned issues, starting with oldest first
* 3) Reviewing 'nobody' or 'imported' bugs starting with the oldest first.
etc..

There is a lot of old cruft in the tracker. Many of the issues have or will be fixed soon, so we could do a lot by just looking at our own issues and setting the status/links appropiately. For all the others, some are just without a decided solution - these would be great ones to at least think about discussing. --[[User:Dan Poltawski|Dan Poltawski]] 17:28, 15 August 2009 (UTC)

Debian Packaging Team

2009-11-01T19:52:14Z

Poltawski: /* php-simpletest */

This page is a shameless abuse of the moodle docs wiki for the debian packaging team to keep track of their goals and not loose mind ;-)

= Removing Embedded Libraries =

== phpmailer ==
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=429339

We can probably fix this by helping changing the way that phpmailer is used in moodle, See MDL-20701

== tinymce ==
In Moodle 1.9 this is not being used (I dont think). In Moodle 2.0 this needs thinking about

== libphp-adodb ==
Won't fix. Moodle customise it.

== libphp-snoopy ==
Lookes like the changes are only in cosmetics. Can go.

== libmarkdown-php ==
We can't fix this one, moodle uses markdown extra

== nusoap ==
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=529573

Doesn't need to be used on debian since we have php5 and soap extension. Removing

== php-simpletest ==
Need to investigate..

: I believe there are a few Moodle-specific tweaks - look in the code:--[[User:Tim Hunt|Tim Hunt]] 19:10, 1 November 2009 (UTC)

:: Just seems to be declaring the $CFG global:
<code php>
diff --git a/lib/simpletestlib/test_case.php b/lib/simpletestlib/test_case.php
index 62d0349..91835a3 100644
--- a/lib/simpletestlib/test_case.php
+++ b/lib/simpletestlib/test_case.php
@@ -458,6 +458,7 @@
*/
function _requireWithError($file) {
$this->_enableErrorReporting();
+ global $CFG; // Moodle patch for $CFG global in unit test files
include($file);
$error = isset($php_errormsg) ? $php_errormsg : false;
$this->_disableErrorReporting();

</code>

Debian Packaging Team

2009-11-01T17:59:30Z

Poltawski:

Debian Packaging Team

2009-11-01T17:52:55Z

Poltawski: /* Removing Embedded Libraries */

Debian Packaging Team

2009-11-01T12:23:21Z

Poltawski: /* nusoap */

Debian Packaging Team

2009-11-01T12:15:33Z

Poltawski: /* Removing Embedded Libraries */

Debian Packaging Team

2009-11-01T12:01:45Z

Poltawski: /* libphp-snoopy */

Debian Packaging Team

2009-11-01T11:42:47Z

Poltawski: New page: This page is a shameless abuse of the moodle docs wiki for the debian packaging team to keep track of their goals and not loose mind ;-) = Removing Embedded Libraries = == phpmailer == h...

Broken/Theme changes in 2.0

2009-08-25T21:56:19Z

Poltawski: /* Caching of 'minified' unified stylesheet? */

I think this is a great system. Some comments on specific issues:

1. Browser-specific stylesheets - is it time to move away from these?

The OU system for this is a lot better. We add special classes to body (in addition to whatever's normally there), so you have

<body class="ie ie7">

or

<body class="gecko gecko19">

Classes indicate the browser engine and version so that we can specify a generic engine if a problem affects all versions, or a specific version.

This means you can put the IE exceptions right next to the standard rules and they can be included in all stylesheets for any module. So you do

#mypage .whatever {
/** normal rules */
}

.ie6#mypage .whatever {
/** broken rules */
}

Note that we don't just need exceptions for IE. Over time we've needed rare (single) exceptions for Firefox (hence 'gecko' stuff above; the issue was actually only in gecko18 I think) and WebKit too.

IMO this system should be adopted in core Moodle. It's very simple and is far preferable to either CSS hacks (appalling) or separate stylesheets (unmaintainable).

2. Debugging mode

Maybe developer debug mode should send a special revision number (rev=debug) in order to regenerate the css every time, and send it without the expires header etc. That would probably make it pretty slow though.

Alternatively, this could be an additional option in the debugging page so that you can turn on 'CSS debugging' which would sent the rev=debug on every page, and turn it off when debugging other stuff that isn't css.

having to manually update the number every single time you change css would be a huge annoyance when debugging css problems imo so I think one of these solutions is better.

3. Removing comments

Removing comments would be great.

It's not only a performance issue, but:

a. Because of the performance concern developers (including me) tend to not include comments at all, this is really bad for maintainability.

b. If a student looks into our code and it says something 'unprofessional' like 'only needed because IE sucks' they might in theory complain - yes I have genuinely had a student complaint for using the word 'sucks' in public - so this is another discouragement for developers to comment properly.

4. Performance

If these are served for lifetime (ie expires 10 years in future) as they should be, I think this would actually improve performance for most sites (that see a lot of repeat visits), even if it takes 50x longer to serve the css itself...

That's it, everything else is awesome. :)

[[User:sam marshall|sam marshall]]

------

2. from sam's suggestions is already done. We should make sure it is not lost in any changes.

I don't see any point in multiple parent themes. Too complicated. Theme + parent + standard is sufficient. I guess once you are at two parents like that, it is no harder to code a general array, it is just much easier for theme developers to screw up. Oh, I guess there is not harm in the extra flexibility.

No problem that this does not include ->requires->css. We should comment that to make it clear that you rarely need to use it, but keep it as an emergency fallback for people who are doing random customisations.

I proposed getting rid of meta.php before, but martin vetoed it. Somewhere in the themes forum is a post form me where I list all the ways it is currently used in core and contrib. I still think we should get rid of it.

Moodle 1.9 themes still work in Moodle 2.0. I would like that to continue to be true. I think it is still possible. Look at the code in theme_config class for handling legacy config.php files, and the code in deprecatedlib.php that implements the old function for serving CSS.

--[[User:Tim Hunt|Tim Hunt]] 17:00, 21 August 2009 (UTC)

------

2. yes, I considered this too - I called this theme designer mode. I am not a big friend to using DEBUG_DEVELOPER for this, that is why I proposed it as separate option.

Why not multiple parents when it is so easy to implement?

I do not understand the "emergency need" for ->requires->css() - the /local/ plug-ins are the correct place for emergency hacks, not the core. You just create new dir in /local/something/styles.css and it will be included automatically on all pages. The problem with custom CSS is that it can not fit into the one huge stylesheet - you can not load it before it because YUI reset will alter it and also after because it would not by style-able via themes which is not an option imo.

I wanted to intentionally disable all old themes, I agree it should be as easy to upgrade as possible, but I still think that admins should be required to take some actions manually or else they will keep complaining that themes are "broken" in 2.0 and nobody told them they should update them. I think the ideal solution would be to allow easy downloads of themes via the Moodle UI instead of full backwards compatibility :-)

[[User:Petr Škoda (škoďák)|Petr Škoda (škoďák)]] 19:34, 21 August 2009 (UTC)

:I think the thing is that for a lot of less experienced admins, for example, the teacher in a school who does it in their same time, they may have tinkered with their theme in the past (or the person before them may have) and they may not remember what was done. Tinkering with the theme, for example changing the logo or a few colours, may be one of the most For them, we want the upgrade to be as simple as possible. If we cannot keep their old theme working, is there any way we can automate the upgrade? Or do we just encourage them to use one of Patrick Malley's nice new themes, and show them how easy it is to add their own logo to one?--[[User:Tim Hunt|Tim Hunt]] 20:09, 21 August 2009 (UTC)

------

I like the sound of these proposals generally.

1) Themes in dataroot: I assume the intention is to completely remove any executable code in these themes?

2) Breaking backwards compatibility: This is the one close to my heart, I just did a quick find and it'll mean we have to update 1003 custom themes (as today stands) which will obviously be a big barrier to Moodle 2.0 upgrade. Having said that I don't necessarily think its a bad idea. Having 'limited' backwards compatibility where by the theme 'just' works might be of limited value (i'm sure we'd need to convert all themes eventually anyway). We need to come up with clear reasons why we need to break backwards compatibility to satisfy less tolerant people than me though ;-)

3) Removing $CFG->themeww/themedir. From anecdotal evidence I think I might be the only person in the world using this feature and I think there are probably better ways to achieve what we are doing, so I am not going to argue very hard to keep it..

I wrote some guidelines to give theme authors a few years ago, which sort of documents the stupid things we get in submitted themes (overriding all styles, uncessarily altering header/footer etc). I put these in Moodle Docs, might be interesting to you or not: [[CLEO_Moodle_Theme_Guidelines]].

In most cases, the 'flexibilty/power' we give theme authors at the moment leads to more breakage due to use of unnecessary modifications in something which could be achieved in a 10 line css file..

--[[User:Dan Poltawski|Dan Poltawski]] 09:45, 22 August 2009 (UTC)

------

== Caching of 'minified' unified stylesheet? ==
Shortly after Tim did his javascript cleanup, I did a hacky little test of minifying all included javascript and caching it by md5 hash. I didn't get very far, but one thing I did notice was that the minification process was surprisingly slow. Serving the single stylesheet might suffer from this problem also if we do additional processing. Do we need caching of the compiled stylesheets?
--[[User:Dan Poltawski|Dan Poltawski]] 19:29, 25 August 2009 (UTC)

Yes, we definitely need caching. I am pretty sure that is in the proposal.--[[User:Tim Hunt|Tim Hunt]] 21:18, 25 August 2009 (UTC)

Apologies.. just found 'storing of final CSS files in dataroot - caches need to be deleted after each theme revision change; this could significantly reduce server load' --[[User:Dan Poltawski|Dan Poltawski]] 21:56, 25 August 2009 (UTC)

Broken/Theme changes in 2.0

2009-08-25T19:29:37Z

Poltawski:

Czech Hackfest 2009

2009-08-25T19:21:32Z

Poltawski: correcting my surname ;-)

Work in progress here - do not rely on this yet.

== Programme ==

; Saturday 5th December 2009 :

* Meet each others in Prague (some arrive, some may be there already)
* Settle down in a hotel - probably [http://www.andelshotel.com] or [http://www.angelohotel.com] (we are discussing with them to get some sale, do not book anything yet).
* Explore Prague (Castle etc)
* Social beer event

; Sunday 6th December 2009 :
* Leaving Prague together by a rented micro-bus (about 120 mins)
* Lunch at [http://www.jested.cz Jested, Liberec].
* Moving to the mountains (by bus or car or foot ;-), according to snow conditions)
* Accommodating at [http://www.dudovi.cz/jizerka/eng/ubytovani.htm Jizerka]

; Monday 7th December 2009
* Moodle 2.0 release planning
* Triage of remaining bugs (assign developers, priorities)
* Bug sprint

; Tuesday 8th December 2009
* Moodle 2.x planning
* Creating detailed roadmap for all modules based on tracker

; Wednesday 9th December 2009
* Moodle 3.0 brainstorming and planning
* Moodle 2.0 bugs

; Thursday 10th December 2009
* Moodle 2.0 bugs
* Skiiing?

; Friday 11th December 2009
* moving back to Prague on Friday
* more Prague sightseeing
* Settle down in a hotel - probably again [http://www.andelshotel.com] or [http://www.angelohotel.com] (we are discussing with them to get some sale, do not book anything yet).
* official end of hackfest

== Attendees and arrivals ==

Maximum of 16 places, so far we have (in chaotic order):

# Martin Dougiamas
# Eloy Lafuente
# Petr Skoda
# Tim Hunt
# Helen Foster
# Penny Leach
# Dan Poltawski
# David Mudrak
# Shane Elliott
# Chris Roy
# ...
# ...
# ...
# ...
# ...
# ...

== Suggestions ==

I wanted to add some ideas of things we could talk about, and for some reason I did not want to use the talk page so I am adding them here. These are just ideas. Take them or leave them.

===What is the balance between Yack and Hack?===

That is, how much time will we be talking, and how much time writing code on our laptops?--[[User:Tim Hunt|Tim Hunt]] 09:41, 8 August 2009 (UTC)

===Planning specific bits of the post 2.0-roadmap===

The main thing is that we keep talking about how recent released, especially 2.0, have had a lot of under the hood changes and that we really need to do some work on the actual activities themselves. I was wonder if if we should have a section of time allocated to what we consider the most important modules (or other things like the gradebook/filepicker/backup).

In order to have meaningful discussion, I suggest that in advanced of the hackfest, each participant is assigned (or volunteers for) one of those bit. They are then expected to read every open bug and feature request for that component, and spend some time following the associated forum, and come up with a summary of what the most pressing issues there seem to be. Then at the hackfest they would lead that discussion section, kicking off by explaining to the rest of us what they learned during their research.

Naturally, if we do this, I volunteer for the quiz and question bank. Of course, I already have a pretty good idea what is going on there. I guess this would probably be more work if people had to look at an area they had not thought about before, so that is not fair.--[[User:Tim Hunt|Tim Hunt]] ~10:00, 6 August 2009 (UTC)

: +1. Naturally, I volunteer for Workshop, given that the Tim's last sentence applies for my case, too. --[[User:David Mudrak|David Mudrak]] 10:51, 7 August 2009 (UTC)

===How about a work-on-2.0 day===

The aim would be that by the end of the day, we have fixed as many of the Fix-for 2.0 bugs as possible, and also have reviewed all the ones that we cannot fix immediately, so we end up with a really good, triaged bug-list of what is left to be done. By the end of the day, all the bugs should be assigned to someone who feels confident they will be able to fix it.--[[User:Tim Hunt|Tim Hunt]] 09:41, 8 August 2009 (UTC) and Dan Poltawski. We discussed this at the GBBF last night.

==='Prepared' Bug Squashing===

Basically the same as the above suggestion, but I want to emphasise some preperation beforehand so that we can get to the real unsolved issues which would benefit with us all being in the same room and discussing solutions.

With each bug we triage before the hackfest, we should try to:
* a) Link or close issues which have been fixed, or will be fixed by 2.0 (etc)
* b) Document unsolved issues which we need discussion or a plan to be fixed ('''this is most important for the hackfest itself''')
* c) Document bugs which could be fixed with a little time (at the hackfest or later)
* d) Document bugs to pester someone else about ;-)

Depending on how much time you can devote, I suggest trying these triaging views in order:
* 1) Reviewing all open bugs reported by yourself, starting oldest first.
* 2) Reviewing your assigned issues, starting with oldest first
* 3) Reviewing 'nobody' or 'imported' bugs starting with the oldest first.
etc..

There is a lot of old cruft in the tracker. Many of the issues have or will be fixed soon, so we could do a lot by just looking at our own issues and setting the status/links appropiately. For all the others, some are just without a decided solution - these would be great ones to at least think about discussing. --[[User:Dan Poltawski|Dan Poltawski]] 17:28, 15 August 2009 (UTC)

Broken/Theme changes in 2.0

2009-08-22T09:46:09Z

Poltawski:

Broken/Theme changes in 2.0

2009-08-22T09:45:27Z

Poltawski: Dans comments on Petr's proposal

I think this is a great system. Some comments on specific issues:

1. Browser-specific stylesheets - is it time to move away from these?

The OU system for this is a lot better. We add special classes to body (in addition to whatever's normally there), so you have

<body class="ie ie7">

or

<body class="gecko gecko19">

Classes indicate the browser engine and version so that we can specify a generic engine if a problem affects all versions, or a specific version.

This means you can put the IE exceptions right next to the standard rules and they can be included in all stylesheets for any module. So you do

#mypage .whatever {
/** normal rules */
}

.ie6#mypage .whatever {
/** broken rules */
}

Note that we don't just need exceptions for IE. Over time we've needed rare (single) exceptions for Firefox (hence 'gecko' stuff above; the issue was actually only in gecko18 I think) and WebKit too.

IMO this system should be adopted in core Moodle. It's very simple and is far preferable to either CSS hacks (appalling) or separate stylesheets (unmaintainable).

2. Debugging mode

Maybe developer debug mode should send a special revision number (rev=debug) in order to regenerate the css every time, and send it without the expires header etc. That would probably make it pretty slow though.

Alternatively, this could be an additional option in the debugging page so that you can turn on 'CSS debugging' which would sent the rev=debug on every page, and turn it off when debugging other stuff that isn't css.

having to manually update the number every single time you change css would be a huge annoyance when debugging css problems imo so I think one of these solutions is better.

3. Removing comments

Removing comments would be great.

It's not only a performance issue, but:

a. Because of the performance concern developers (including me) tend to not include comments at all, this is really bad for maintainability.

b. If a student looks into our code and it says something 'unprofessional' like 'only needed because IE sucks' they might in theory complain - yes I have genuinely had a student complaint for using the word 'sucks' in public - so this is another discouragement for developers to comment properly.

4. Performance

If these are served for lifetime (ie expires 10 years in future) as they should be, I think this would actually improve performance for most sites (that see a lot of repeat visits), even if it takes 50x longer to serve the css itself...

That's it, everything else is awesome. :)

[[User:sam marshall|sam marshall]]

------

2. from sam's suggestions is already done. We should make sure it is not lost in any changes.

I don't see any point in multiple parent themes. Too complicated. Theme + parent + standard is sufficient. I guess once you are at two parents like that, it is no harder to code a general array, it is just much easier for theme developers to screw up. Oh, I guess there is not harm in the extra flexibility.

No problem that this does not include ->requires->css. We should comment that to make it clear that you rarely need to use it, but keep it as an emergency fallback for people who are doing random customisations.

I proposed getting rid of meta.php before, but martin vetoed it. Somewhere in the themes forum is a post form me where I list all the ways it is currently used in core and contrib. I still think we should get rid of it.

Moodle 1.9 themes still work in Moodle 2.0. I would like that to continue to be true. I think it is still possible. Look at the code in theme_config class for handling legacy config.php files, and the code in deprecatedlib.php that implements the old function for serving CSS.

--[[User:Tim Hunt|Tim Hunt]] 17:00, 21 August 2009 (UTC)

------

2. yes, I considered this too - I called this theme designer mode. I am not a big friend to using DEBUG_DEVELOPER for this, that is why I proposed it as separate option.

Why not multiple parents when it is so easy to implement?

I do not understand the "emergency need" for ->requires->css() - the /local/ plug-ins are the correct place for emergency hacks, not the core. You just create new dir in /local/something/styles.css and it will be included automatically on all pages. The problem with custom CSS is that it can not fit into the one huge stylesheet - you can not load it before it because YUI reset will alter it and also after because it would not by style-able via themes which is not an option imo.

I wanted to intentionally disable all old themes, I agree it should be as easy to upgrade as possible, but I still think that admins should be required to take some actions manually or else they will keep complaining that themes are "broken" in 2.0 and nobody told them they should update them. I think the ideal solution would be to allow easy downloads of themes via the Moodle UI instead of full backwards compatibility :-)

[[User:Petr Škoda (škoďák)|Petr Škoda (škoďák)]] 19:34, 21 August 2009 (UTC)

:I think the thing is that for a lot of less experienced admins, for example, the teacher in a school who does it in their same time, they may have tinkered with their theme in the past (or the person before them may have) and they may not remember what was done. Tinkering with the theme, for example changing the logo or a few colours, may be one of the most For them, we want the upgrade to be as simple as possible. If we cannot keep their old theme working, is there any way we can automate the upgrade? Or do we just encourage them to use one of Patrick Malley's nice new themes, and show them how easy it is to add their own logo to one?--[[User:Tim Hunt|Tim Hunt]] 20:09, 21 August 2009 (UTC)

------

I like the sound of these proposals generally.

1) Themes in dataroot: I assume the intention is to completely remove any executable code in these themes?

2) Breaking backwards compatibility: This is the one close to my heart, I just did a quick find and it'll mean we have to update 1003 custom themes (as today stands) which will obviously be a big barrier to Moodle 2.0 upgrade. Having said that I don't necessarily think its a bad idea. Having 'limited' backwards compatibility where by the theme 'just' works might be of limited value (i'm sure we'd need to convert all themes eventually anyway). We need to come up with clear reasons why we need to break backwards compatibility to satisfy less tolerant people than me though ;-)

3) Removing $CFG->themeww/themedir. From anecdotal evidence I think I might be the only person in the world using this feature and I think there are probably better ways to achieve what we are doing, so I am not going to argue very hard to keep it..

I wrote some guidelines to give theme authors a few years ago, which sort of documents the stupid things we get in submitted themes (overriding all styles, uncessarily altering header/footer etc). I put these in Moodle Docs, might be interesting to you or not: [[CLEO_Moodle_Theme_Guidelines]] In most cases, the 'flexibilty/power' we give theme authors at the moment leads to more breakage due to use of unnecessary modifications in something which could be achieved in a 10 line css file..

--[[User:Dan Poltawski|Dan Poltawski]] 09:45, 22 August 2009 (UTC)