MoodleDocs - User contributions [en]

User:Dan Poltawski

2012-06-28T14:28:52Z

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 :))

Development: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.

Development talk:Cohorts

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)

Development: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)

Development: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)

Development: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)

Development: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>

Development:Debian Packaging Team

2009-11-01T17:59:30Z

Poltawski:

Development:Debian Packaging Team

2009-11-01T17:52:55Z

Poltawski: /* Removing Embedded Libraries */

Development:Debian Packaging Team

2009-11-01T12:23:21Z

Poltawski: /* nusoap */

Development:Debian Packaging Team

2009-11-01T12:15:33Z

Poltawski: /* Removing Embedded Libraries */

Development:Debian Packaging Team

2009-11-01T12:01:45Z

Poltawski: /* libphp-snoopy */

Development: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...

Development talk: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)

Development talk:Theme changes in 2.0

2009-08-25T19:29:37Z

Poltawski:

Development: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)

Development talk:Theme changes in 2.0

2009-08-22T09:46:09Z

Poltawski:

Development talk: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)

Development talk:Theme changes in 2.0

2009-08-22T09:44:57Z

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:44, 22 August 2009 (UTC)

Development:Developer documentation

2009-08-16T20:26:41Z

Poltawski: updated security link

This [[:Category:Developer|Developer]] section of Moodle Docs is aimed at developers who contribute to the Moodle code, plugins, themes, and so on.
* If you manage a Moodle site, [[Administrator documentation]] may suit your needs better.
* If you teach using Moodle, try [[Teacher documentation]].

'''Note:''' New developer documentation pages should be added to the ''Development namespace'' by typing <code>Development:</code> before the new page name i.e. <code><nowiki>[[Development:New page name]]</nowiki></code>. If you are a developer, you probably want to change your [[Special:Preferences|preferences]] to include the Development namespace in searches. 

A page may be added to the Developer category by adding the template <code><nowiki>{{CategoryDeveloper}}</nowiki></code> to the bottom of the page. - If required, you can use <code><nowiki>[[Category:Developer|Sort key]]</nowiki></code> to provide a sort key other than the default page name.

==How Moodle development works==

The [[Development:Overview|overview of the Moodle development process]] explains how Moodle development occurs and how people become Moodle developers. Current plans are listed on the [[Roadmap]].

You can also enrol in one of the [http://dev.moodle.org Moodle Developer Courses].

==Guidelines==

The following guidelines are crucial reading for anyone wanting to contribute to the Moodle code base:
*[[Development:Coding|Coding guidelines]] have to be followed by all Moodle developers
*[[Moodle design goals]] spells out the basic design goals behind Moodle
*[[Interface guidelines]] aim to provide a common feel to the Moodle user interface
*[[CVS (developer)|Moodle CVS for developers]] explains how to work with the Moodle code in CVS
*[[Tracker]] explains the Moodle Tracker for keeping track of bugs, issues, feature requests etc
*[[Development:Working with the Community|Working with the Community]] explains how to engage with the dev community and discuss changes
*[[Development:Unit tests|Unit tests]] explains how to run the unit tests, and how to write new test cases.
*[[Development:Fast portable SQL]] shows SQL techniques that are fast, efficient, and known to work on all supported DBs.

==Documentation for core components==

This section is for documentation of specific components of the existing core Moodle code. Discussion of components that are under discussion or in development can be found in the [[Development:Developer notes|developer notes]] or on the [[Roadmap|roadmap]].

The documents below give a general overview. For detailed function-by-function documentation, see the [http://phpdocs.moodle.org/ phpDocumentor] documentation that is automatically generated from the comments in the code.

And don't forget that the most up-to-date and detailed description of how the code works is the code itself, and you can [http://xref.moodle.org/nav.html?index.html browse the code online] using [[Development:PHPXref|PHPXref]].

===Core components that affect everything===

*[[Development:Database schema introduction|The database schema]]
*[[Development:What happens when you require config.php|What happens when you require config.php]]
*lib/moodlelib.php
*[[Development:lib/weblib.php|lib/weblib.php]] for outputting stuff
*[[Development:JavaScript_functions|JavaScript function available on the client side]]
*[[Development:XMLDB_Documentation|Database abstraction layer]] @ v[[1.7]]
*[[Development:Roles|Roles and Capabilities system]] @ v[[1.7]] for controlling who can do what
*[[Development:lib/formslib.php|Forms library]] @ v[[1.8]] for creating accessible and secure HTML forms that let users edit things
*[[Development:Using_the_file_API|File API]] @ v[[2.0]] for managing files stored by Moodle

===Core libraries with a more specific uses===

*[[Authentication API]]
*[[Cookieless Sessions]]
*[[Email processing]]
*[[Development:Environment checking|Environment checking]] before install, check the user's server to ensure Moodle will work there.
*[[Development:Groups|Groups system]]
*[[Development:Grades|Gradebook]]
*[[Development:Moodle Network|Moodle Network]]
*[[Question engine]]
*[[Stats package]]
*[[UTF-8 migration|Migration to UTF-8]] @ v[[:Category:Moodle 1.6|1.6]]
*[http://developer.yahoo.com/yui YUI JavaScript library] - YUI was selected as the official AJAX library for Moodle.
*[[Development:lib/graphlib|lib/graphlib]]
*[[Development:Admin settings|Admin settings]]

===Modules included in the standard distribution===

*[[Development:Lesson Specification|Lesson Specification]]
*[[Quiz developer docs|Quiz module]]
*[[SCORM schema|SCORM module 1.5 schema]]

==How you can contribute==

===Make a new plugin===

The M in Moodle stands for modular, and the easiest, most maintainable way to add new functionality to Moodle is by using one of the many plugin APIs. There are many types of plugin you can write:
*[[Development:Modules|Activity modules]], see also [[Development:NEWMODULE Documentation]] (work in progress)
*[[Development:Admin reports|Admin reports]]
*[[Development:Assignment types|Assignment types]]
*[[Development:Authentication plugins|Authentication plugins]]
*[[Development:Blocks|Blocks]]
*[[Course formats]]
*[[Development:Course Report Plugins|Course reports]]
*[[Development:Database fields|Database fields]]
*[[Development:Database presets|Database presets]]
*[[Development:Enrolment plugins|Enrolment plugins]]
*[[Development:Filters|Filters]]
*[[Development:Gradebook plugins|Gradebook plugins]] (1.9 onwards)
**[[Development:Gradebook_Report_Tutorial|Gradebook report]]
**[[Development:Gradebook export|Gradebook export]]
**[[Development:Gradebook import|Gradebook import]]
*[[Development:Writing_a_Portfolio_Plugin|Portfolio plugins]] (2.0 onwards)
*[[Development:Question_type_plugin_how_to|Question types]]
*[[Development:Question import/export formats|Question import/export formats]]
*[[Development:How to write a quiz report plugin|Quiz reports]]
*[[Development:Repository plugins|Repository plugins]] (2.0 onwards)
*[[Development:Resource types|Resource types]]
*[[Development:Search engine adapters|Search engine adapters]]

General information that applies to all types of plugins
*[[Development:Places to search for lang strings|Where to put language strings for your plugin]]
*[[Development:Installing and upgrading plugin database tables|Defining the database tables for your plugin]]

Please see the [[Development:Guidelines for contributed code|Guidelines for contributed code]] for an overview of how to contribute to the Moodle code.

Sometimes it is not possible to write a proper plugin for what you want to do, in which case you may have to resort to using the [[Development:Local_customisation|local customisations]] hook.

===Change core code===

Some types of change can only be made by editing the core Moodle code. Such changes are much harder to maintain than plugins. If you want your core change to be considered for inclusion in the official Moodle release, you need to create an issue in the [[Tracker|tracker]], and attach your change as a [[Development:How_to_create_a_patch|patch]]. It is also a good idea to discuss your ideas in the forums first. See [[Development:Overview#Major_Development]] for more details.

===Ways to contribute that do not involve PHP programming===

*[[Themes|Create Moodle themes]]
*[[Translation|Translate Moodle into other languages]]
*[[MoodleDocs:Guidelines for contributors|Help document Moodle]]
*[[Development:Tests|Join the testing effort]], which involves [[Tracker|participating in the bug tracker]]

==Plans for the future==

Ideas for and details of planned future features of Moodle are initially discussed on the forums in the [http://moodle.org/course/view.php?id=5 Using Moodle] course at moodle.org. That developer discussions are intermixed with user discussions in the same forums may seem strange at first but is one of the reasons for the success of Moodle. It is important that both end-users and developers discuss the future features together.

Once ideas begin to crystallize on the forums they can be summarized in this wiki, either as part of the [[Roadmap|roadmap]] or in the form of [[Development:Developer notes|developer notes]]. These pages then form the basis for further discussion in the forums.

*[[Roadmap]]
*[[Development:Developer notes|Developer notes]]
*[[Student projects]]
*[[Developer meetings]]

== Resources ==

*[[Developer FAQ]] - frequently asked questions, especially useful for newcomers to Moodle
*[[Development:Finding_your_way_into_the_Moodle_code|Finding your way into the Moodle code]] - also aimed at newcomers
*[http://tracker.moodle.org/ Moodle tracker] - bug reports, feature requests and other tracked issues
**[[Firefox tracker search]] - How to setup a firefox quicksearch to easily navigate to moodle bugs
**[[Firefox tracker search#Firefox Search Plugins|Firefox Search Plugins]] - Find tracked issues even more easily
*[[Unmerged files]] - changes on the stable branch in CVS that have not been merged to [[HEAD]]
*Browse the code online:
**[http://cvs.moodle.org/moodle/ the code with a complete change history from CVS]
**[http://xref.moodle.org/index.html the code, with links generated by PHPXref]
*[http://phpdocs.moodle.org/ Moodle PHP doc reference] - compiled from the comment attached to each class and function in the code
*[[Development:Database Schema|Database Schema]] - for recent releases
*[http://moodle.org/course/view.php?id=5#4 Development news and discussion] section of Using Moodle course
**especially the [http://moodle.org/mod/forum/view.php?id=55 General developer forum]
**[[Filters used on the Moodle.org forums|cool tricks you can use in the moodle.org forums]]

== Tools ==
Some tools people use when working on Moodle code:

=== IDEs ===

* [[Development:Setting_up_Netbeans|Setting up NetBeans for Moodle development]] - NetBeans for PHP is a great out-of-the-box editor.
* [[Development:Setting_up_Eclipse|Setting up Eclipse for Moodle development]] - Eclipse is a great editor to use for php development, if you can work out how to set it up.
* [[Development:vim|Setting up Vim for Moodle development]]

=== Browser add-ons ===
*[http://getfirebug.com Firebug], see [[Development:Firebug]].
* [[Web developer extension]]
* [https://addons.mozilla.org/en-US/firefox/addon/394 ViewSourceWith] - The main goal is to view page source with external applications, but you can do a lot of other things as well.

=== Miscellaneous ===
*[[Development:ctags|Ctags]] - Using a tags file to navigate code
*[[W3C_validation|W3C HTML validator]] - Moodle has built in support to make using it easier.
*[[Development:Windows Installer|Windows Installer]] - Windows Installer documentation for developer.

See also: [http://dev.moodle.org/mod/forum/view.php?id=18 Useful Development Tools forum]in the [http://dev.moodle.org/course/view.php?id=2 Introduction to Moodle Programming course]

==See also==

*[http://moodle.org/security/ Moodle Security Announcements]
*[http://moodle.com/partners/ Moodle Partners] - providers of custom Moodle development services

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

[[ru:Development:Краткий обзор]]
[[es:Documentación para Desarrolladores]]
[[fr:Documentation développeur]]
[[pt:Desenvolvimento:Documentação para programadores]]
[[zh:开发者文档]]
[[ja:開発者ドキュメント]]
[[fi:Ohjelmoijan opas]]

Development:Czech Hackfest 2009

2009-08-15T17:28:28Z

Poltawski: Adding my idea about 'prepared bug squashing'

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
; Tuesday 8th December 2009
; Wednesday 9th December 2009
; Thursday 10th December 2009
; Friday 11th December 2009
* bugathon
* polishing 2.0
* planning roadmap for Moodle 2.x and 3.0
* hacking
* talking
* drinking
* skiing
* snow-balling
* making Moodle snow-man
* etc

; 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 D
# Eloy L
# Petr S
# Tim H
# Helen F
# Penny L
# Dan P
# David M
# Shane E
# Chris P

== 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)

Theme reference

2009-06-24T21:57:26Z

Poltawski: adding link to cleo moodle guidelines

{{Themes}}
This is a reference manual for the theme class and id values. It is based on Moodle 1.54. Please make a note for items that are 1.6, 1.7, 1.8, or 2.0 specific.

==Login Page==

*The main part of the page above the breadcrumb navigation.

div id = "page" - The background of the whole page. 
div id = "header" - The header section of the page. 
div class = "headermain" 
div class = "headermenu" 
div class = "logininfo" 

*The breadcrumb navigation.

table class = "navbar" - Box surrounding the naviational items. 
div class = "breadcrumb" - navigational breadcrumb text. 
div class = "navbutton" - drop down box for language selection. 
div class = "langmenu" - drop down box for language selection. 

*The actual content of the page

div id = "content" 
table class = "loginbox" 
div class = "header left" 
div class = "header right" 
td class = "content left" 
td class = "content right" 

<pre>
/* adds a background image to the content of the login box
on both the right and left side */
.loginbox .content {
border-color:#DDDDDD;
background-color: white;
background-image:url(gen_background2.jpg);
}

/* adds a background image to the header text
above the login box on both the right and left side */
#content .header {
border-color: #dddddd;
background-color:#FCFCFC;
background-image: url(cellpic3.gif);
color: #dddddd;
}
</pre>

Note: There is class called "content" and there is an id called "content". Make sure that you are referencing the correct one.

Note: "header" is a class name and an id name. Be careful.

==Main Page==
===Course view===

===Category view===

==Course Page==

===Topic view===

===Week view===

===Social view===

==Calendar Page==

==Blog Page==

==Assignments Page==

==Chat Page==

==Choice Page==

==Forum Page==

==Glossary Page==

==Hot Pot==

==Lesson Page==

==Quiz Page==

==Resource Page==

==SCORM Page==

==Survey Page==

==Wiki Page==

==Workshop Page==

== See Also
* [[CLEO Moodle Theme Guidelines]]

Development talk:Coding style

2009-06-12T00:15:06Z

Poltawski: Martin & Eloy are not cool (tm)

== PHP5 constructor ==

Should we enforce the PHP5 constructor __construct() instead of $classname() [[User:Nicolas Connault|Nicolas Connault]] 19:55, 19 May 2009 (UTC)
:+1. I think we agreed about that some time ago (when igniting some 2.0 developments) --[[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 00:03, 20 May 2009 (UTC)

== Inline comments ==

I have been using since ages ago "///" with outer alignment (I think that it was caused by some agreement long time ago, not my decision), for example:

<code php>
function check_moodle_environment(..., ..., ..., ...) {

$status = true;

/// This are cached per request
static $result = true;
static $env_results;
static $cache_exists = false;

/// if we have results cached, use them
if ($cache_exists) {
$environment_results = $env_results;
/// No cache exists, calculate everything
} else {
/// Get the more recent version before the requested
if (!$version = get_latest_version_available($version, $env_select)) {
$status = false;
}
....
....
</code>
Is that allowed, or only the "//" with inner alignment as commented at [[Development:Coding style#Inline comments|inline comments]] --[[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 00:03, 20 May 2009 (UTC)

I did start doing all mine this way, but if you look at the code it seems you and I are the only ones. :P It seems sensible to make the standard fit what most people are used to (and how most of the code looks).
-- [[User:Martin Dougiamas|Martin Dougiamas]] 06:02, 9 June 2009 (UTC)

Eloy and Martin, this the only thing which consistently offends me about moodle coding style! Please go inline like all the cool kids ;-) --[[User:Dan Poltawski|Dan Poltawski]] 00:15, 12 June 2009 (UTC)

==Trailing spaces==

"Lines should not contain trailing spaces. In order to facilitate this convention, most editors can be configured to strip trailing spaces, such as upon a save operation. However, if you are editing an existing Moodle file and are planning to submit your changes to CVS, please switch off that feature so that whitespace changes do not pollute CVS history (other developers will have trouble viewing what you've done if every other line has been edited for whitespace)."
Wouldn't the CVS history only get 'polluted' when someone fetched a file that DIDN'T follow this principle and returned it following the principle? Isn't that the price that has to be paid to clean things up? Otherwise this is pretty scary for someone who feels: "Great I can turn on my editor to autostrip those when saving. BUT I have to remember to turn that off if submitting it! (Or become a 'polluter'!)"
And what happens if I have already saved it locally while working on (and striped those trailing spaces) and later try to commit it. Maybe my ignorance about CVS is making me pose a "silly" question. [[User:Jeff Forssell|Jeff Forssell]] 07:17, 27 May 2009 (UTC)

: Jeff, the point with coding guidelines is that all new code must follow all the guidelines. With old bad code, mostly it is better to make the smallest change necessary when, for example, you fix a bug. That makes it clearest what the purpose of your change was. However, any line you do change while fixing the bug, you can then improve the coding style on that line.

: Really good editors actually have an option "Strip trailing whitespace when saving a file - but only from lines that I have edited", which is what you really want.

: The real way to avoid being a CVS polluter is to follow the best practice and always do a cvs diff and review all your changes (and if necessary amend them) before you do a CVS commit.--[[User:Tim Hunt|Tim Hunt]] 03:52, 1 June 2009 (UTC)

=== Breaking up lines (e.g. huge arrays) ===

The coding style says to align the start of the following lines with the element in the first.. e.g.

<code php>
$myarray = array( 'fred' => 'blue',
'tom' => 'green' );
</code>

I have to say I don't like this. While it looks very pretty it is a code maintenance nightmare. If you change (say) the array name you have to change every other line just to keep it looking nice. Surely if you '''must''' have it looking like this, do this...

<code php>
$myarray = array(
'fred' => 'blue',
'tom' => 'green' );
</code>

It's the same issue with long lists of assignments - making all the RHSs line up. Completely unnecessary and just asking for errors. Don't encourage people to change code that they don't have to. If they don't touch it then they can't break it. --[[User:Howard Miller|Howard Miller]] 13:52, 1 June 2009 (UTC)

:Agree 100% with Howard, I prefer the 2nd alternative for sure, if not always, at least in places where indentation is already considerable. BTW, same for harcoded SQLs and other strings. --[[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 13:58, 1 June 2009 (UTC)

: +1 from me too for a fixed indent for follow-on lines. Actually I have always used 8-spaces (double the normal indent) ever since I started programming in Java and read their docing guidelines. I think it is helpful to have a different level of indent for a follow-on line and a block.

: Sure, makes sense. I've fixed the docs. The only exception IMO would be wrapping function parameters, which just look too wierd to me if you wrap them the same as arrays. See [https://docs.moodle.org/en/Development:Coding_style#Wrapping_function_declarations the example]. -- [[User:Martin Dougiamas|Martin Dougiamas]] 06:08, 9 June 2009 (UTC)

Development:NEWMODULE Adding capabilities

2009-05-23T09:46:15Z

Poltawski: remove reference to glossary

{{New_Module}}
In order to add a capabilities for your <<NEWMODULE>> you need to:

==1. Create a file access.php in the <<NEWMODULE>>/db directory==

This should contain a list of the capabilities that you want to define. For example:

<code php>
$mod_<<NEWMODULE>>_capabilities = array(
'mod/<<NEWMODULE>>:<<CAPABILITYNAME>>' => array(
'riskbitmask' => RISK_SPAM | RISK_PERSONAL | RISK_XSS | RISK_CONFIG,
'captype' => 'write',
'contextlevel' => CONTEXT_MODULE,
'legacy' => array(
'student' => CAP_ALLOW,
'teacher' => CAP_ALLOW,
'editingteacher' => CAP_ALLOW,
'admin' => CAP_ALLOW
)
),

// Add more capabilities here ...
)
</code>

The various parts of the capability definition are:

===Capability name ('mod/<<NEWMODULE>>:<<CAPABILITYNAME>>)===

This is the internal name used for this this capability. In addition to this internal name, you should also add the language string <<NEWMODULE>>:<<CAPABILITYNAME>> to your module's language file, to give the capability a name that users will see in the interface.

===riskbitmask===

Allowing people to do various things sometimes requires introducing possible security risks. For example, if you can post to a forum, you can post unsolicited advertising. To a certain extent users have to be trusted. To help administrators and teachers know what the issues are, each capability should list any associated risks. See [[Development:Hardening_new_Roles_system]]. will be reflected in the list of icons of each row of the 'Override permissions'->roles page.

Technically, this value is a bit field, so you should combine the relevant risks constants with the '|' operator. So typical values might be:
* RISK_SPAM
* RISK_PERSONAL | RISK_XSS | RISK_DATALOSS

===captype===

Should be either 'read' or 'write'. 'read' is for capabilities that just let you view things. 'write' for capabilities that let you change things.

===contextlevel===

The context level where this capability is most relevant. If you are writing a module this will almost always be CONTEXT_MODULE. (This does not have much effect. It is just used to sort and group capabilities on the define roles and override roles pages.)

===legacy===

This is badly named, it would be better called 'defaultpermissions' or something.

This section defines, for each legacy role type, what permissions those roles should be given when your module is first installed (or when a new capability is detected on upgrade).

Normally, you just add one line for each role that you want to give the capability to. The line should look like 'roletype' => CAP_ALLOW. Just leave out roles that you do not want to get the capability be default. Very exceptionally, you may need to specify a default permission of CAP_PREVENT, CAP_PROHIBIT.

==2. Get Moodle to load the updated capabilities==

The capabilities you defined are only read (and copied into the Moodle database) when your module is installed or upgraded. So every time you edit the db/access.php file you must
# Increase your module's version number by editing the file mod/<<NEWMODULE>>/version.php.
# Go to the the Administration ► Notifications page, and click through the steps to let Moodle upgrade itself. You should see the name of your module in one of the steps.

==3. Checking the capability in your code==

In order to check whether the current user has a particular capability, you need to use the has_capability function. To do that, first you have to get the appropriate context. In this case, it will be a module context.

1. First we need to get the $cm id, and verify that it is correct (there are lots of different ways you might do this, this is only an example.
<code php>
$cmid = required_param('cmid', PARAM_INT);
if (!$cm = get_coursemodule_from_id('<<NEWMODULE>>', $cmid)) {
error("Course module ID was incorrect");
}
</code>

2. Then you get the module context:
<code php>
$context = get_context_instance(CONTEXT_MODULE, $cm->id);
</code>

3. Finally, you can actually check the permission
<code php>
if (has_capability('mod/<<NEWMODULE>>:<<CAPABILITYNAME>>', $context)) {
</code>

Normally, you do 1. and 2. once at the top of a script, and then call has_capability as needed within the script with the appropriate capabilities.

===Useful variations===

====Controlling overall access to a script====

Suppose you have a page that should only be available to users with a particular capability. For example, only users with mod/quiz:viewreports should be able to access mod/quiz/report.php. In cases like this, you can use the require_capability function:
<code php>
require_capability($capability, $context);
</code>
near the top of your script. (As soon as you have got the context and called require_login is a good time.) All this does internally is
<code php>
if (!has_capability($capability, $context)) {
// Display error and exit.
}
</code>
but using require_capability makes your code simpler and is recommended. (Of course, anywhere you might print a link to a page like this, you should only print the link if the user has the right capability.)

====Getting a list of users with a capability====

Suppose you need to get a list of all the users with a particular capability. (For example, the quiz reports list all the users with the mod/quiz:attempt capability. Then you can use the get_users_by_capability function.

====Checking the permissions of another user====

There is an optional 3rd parameter to has_capability that you can use to check another user's permissions:
<code php>
has_capability($capability, $context, $otheruser->id);
</code>

====Excluding administrators====

Administrators have a magic 'moodle/site:doanything' capability that gives them every other capability. If you wish to disable that magic override for one particular capability check, you can use the optional 4th parameter to has capability:
<code php>
has_capability($capability, $context, NULL, false);
</code>
However, you normally should not do this.

====Performance considerations====

The has_capability function has been carefully optimised, and is pretty fast and you should not really worry. However, it has to perform a fairly complex computation, and if you are going to make exactly the same has_capability call several times in a page (perhaps in a loop) it is probably worth moving the permission check outside the loop. For example don't do:
<code php>
foreach ($attempts as $attempt) {
if (has_capability('mod/quiz:viewreports', $context)) {
// ...
}
}
</code>
Instead do
<code php>
$canviewreports = has_capability('mod/quiz:viewreports', $context);
foreach ($attempts as $attempt) {
if ($canviewreports) {
// ...
}
}
</code>

get_users_by_capability is a very expensive computation. If you are calling it more than once in your script, you are probably doing something wrong ;-)

==See also==

* [[Development:Roles]]
* [[Development:Hardening_new_Roles_system]] - information about risks
* [[Development:NEWMODULE_Documentation]] - NEWMODULE Documentation front page

{{CategoryDeveloper}}
[[Category:Roles]]

Development:Importing Moodle CVS history into git

2009-05-14T08:57:49Z

Poltawski: mos new versions of git dont have git-commands now

==Importing CVS==

To begin we must import the CVS repository into a local git filesystem using [http://www.kernel.org/pub/software/scm/git/docs/git-cvsimport.html git-cvsimport].

#!/bin/bash
CVSROOT=:pserver:anonymous@uk.cvs.moodle.org:/cvsroot/moodle
MODULE=moodle
INSTALLDIR=moodle
git cvsimport -p x -v -k -o cvshead -d $CVSROOT -C $INSTALLDIR $MODULE &> cvsimport.log

(When might one want to use the -m -u and -s flags?)
-u purely cosmetic
-s slashes can cause problems but this doesn't seem to be the case with moodle
-m ?

This will run for a '''very''' long time as it checks out every revision of each file (including all branches). However, if you run the command after a successful initial run it will simply get the new revisions since it was last run. This creates a new git repository which can then be cloned and worked upon.

At the time of writing the size of a new Moodle git repository was approximately 866MB ''unpacked'', and 75MB packed. Newer versions of git pack the project during import, so your resulting repository plus checkout should be a bit over 100MB. Still, it is a good idea to pack the repository to make it smaller and faster, running

git-repack -a -d

With the -o cvshead flag, the "HEAD" of the CVS repo will appear as 'cvshead' in GIT, making things a lot clearer.

==Importing CVS Faster==

For initial imports, it is highly recommended that you fetch the CVS repository from one of Moodle [[CVS_for_Administrators#CVS_Servers | cvs servers]] and run the initial cvsimport against your local copy of the repository.

:: For the more adventurous: Keith Packard wrote another importer that does a better job at the initial import, called parsecvs. I use parsecvs for the initial import and then git-cvsimport daily for the incremental imports. --[[User:Martin Langhoff|Martin Langhoff]] 15:04, 19 July 2006 (WST)

:: It took me a few minutes to find the info in the Sourceforge docs on how to fetch the raw CVS repo via rsync. Just type 'rsync -av "rsync://moodle.cvs.sourceforge.net/cvsroot/moodle/moodle/*" .' (without the single quotes) and you'll be done --[[User:Iñaki Arenaza|Iñaki Arenaza]] 17:54, 25 December 2006 (CST).

:: This rsync command line doesn't work as-is anymore, since the repository was moved from sourceforge. Some mirrors (at least es.cvs.moodle.org at this time) provide rsync, but some don't (like eu.cvs.moodle.org). Find the best mirror for you and update the rsync call accordingly.

After the initial import, you can run git-cvsimport against your favorite cvs.moodle.org mirror repository, or update your local copy via rsync as sas demonstrated in [http://www.progsoc.org/~wildfire/git/update-repo.sh this script].

== Useful Links ==

* [http://www.kernel.org/pub/software/scm/git/docs/git-cvsimport.html git-cvsimport man page]

[[Category:Developer|Importing Moodle CVS history into git]]

Development:Git Migration Workflows

2009-05-07T09:18:24Z

Poltawski:

= Workflows for Migrating to Git =

Quite a number of developers are now familiar with git and are enthusiastic about the power and flexibility it brings to the development process. It is not clear how workflows in the current development process will transfer if a switch to git is made.

Git doesn't place constraints to one model of development which is both a feature and a hindrance for people understanding how the development process takes place. A number of workflows need to be developed in order that developers can understand how git would fit into moodle development.

Please edit this page to add your suggested workflows or questions for a workflow to do something.

== General Model for Commiting to HEAD ==

'''Summary''': How do developers 'commit' to the canonical repository?

* Developers 'push' to a central repository as happens with CVS now. Commit access is granted via ssh. (But external contributors can publish their git repository branches to developers with commit access for inclusion to the mainline)
* Developers push to their personal repository and an integrator/gatekeeper approves and merges changes (e.g. linus kernel branch)
* Others/hybrid approaches?

== Commiting to STABLE branches ==
'''Summary''': How do developers commit to the stable branches? How do we ensure changes have been merged into head?

[[Category:Developer|Git]]
[[Category:Developer tools|Git]]

Development:Git Migration Workflows

2009-05-07T09:17:19Z

Poltawski: New page: = Workflows for Migrating to Git = Quite a number of developers are now familiar with git and are enthusiastic about the power and flexibility it brings to the development process. It is ...

Projects for new developers

2009-03-26T13:57:14Z

Poltawski: adding myself

Moodle will be taking part in the [http://socghop.appspot.com/ Google Summer of Code] for our fourth year in 2009!

If you're thinking of applying to work with Moodle for GSOC 2009, please see [[Applying to work with Moodle for GSOC]].

This evolving page lists possible Moodle projects for new developers derived from community suggestions.

''If you have any ideas for new features in Moodle which might be suitable as GSOC projects, please see [[Development:New feature ideas]].''

==Custom report generator==

An interface for enabling Moodle admins to create custom reports.

:'''Skills required''': PHP
:'''Difficulty level''': Medium
:'''Mentors''': To be confirmed

For further details see:
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=116895 Feature for creating custom reports] forum discussion
* Tracker issue MDL-18323

==Record audio repository plugin==

Use a Flash or Java plugin to record the audio to a suitable compressed format. The data could then be uploaded as for a File upload plugin.

:'''Skills required''': PHP and Flash or Java
:'''Difficulty level''': Medium
:'''Mentors''': To be confirmed

For further details see:
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=117135 Record audio repository plugin] and [http://moodle.org/mod/forum/discuss.php?d=116968 GSOC: Record Audio/Video directly into resources/activities] forum discussions
* Tracker issue MDL-18341

==Google Gears integration==

:'''Skills required''': PHP
:'''Difficulty level''': Medium
:'''Mentors''': To be confirmed

For further details see:
* http://gears.google.com
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=118015 Google Gears integration] and [http://moodle.org/mod/forum/discuss.php?d=107920 OLPC and GG-based offline-moodle] forum discussions
* Tracker issue MDL-18444

==XML admin settings presets==

Create an interface for allowing administrators to export settings in an XML file for restoring to another Moodle site.

:'''Skills required''': PHP
:'''Difficulty level''': Medium
:'''Mentors''': [http://moodle.org/user/view.php?id=17383&course=5 Penny Leach] [http://moodle.org/user/view.php?id=104159&course=5 Dan Poltawski]

For further details see:
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=118494 GSOC project: XML admin settings presets] forum discussion
* Tracker issue MDL-18548

==Workflow support in the Database activity module==

Add the ability to control the state of a database record, permissions at different state levels and email notifications.

:'''Skills required''': PHP and understanding UML syntax of [http://en.wikipedia.org/wiki/State_diagram state diagrams], workflow principles
:'''Difficulty level''': Medium
:'''Mentors''': [https://docs.moodle.org/en/User:David_Mudrak David Mudrák]

For further details see:
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=118830 Workflow support] forum discussion
* Tracker issue MDL-18572

==Flash-Based Statistics Visualizer==

Continue work done by [http://hackerdan.com/ Dan Servos] for GSoC 2008 to create a Moodle plugin that can visualize grades and other statistics interactively through a browser. The [http://hackerdan.com/gsoc/screen-cast/ current version] allows users to do correlations, time-series charts, etc., on a lot of the data Moodle records; more viz tools, export, etc., would make it extremely useful to people dealing with large courses.

:'''Skills required''': PHP and Flash
:'''Difficulty level''': Medium
:'''Mentors''': [mailto:gvwilson@cs.toronto.edu Greg Wilson]

For further details see:
*[[Student projects/Animated grade statistics report]]

==What You Paint Is What You Get extension to the WYSIWYG editor==

Younger Moodle users like drawing and painting more than writing. Add a feature that lets the main text editor of Moodle switch to "draw" mode.

:'''Skills required''': PHP and Flash or JavaScript or other alternative
:'''Difficulty level''': High
:'''Mentors''': [http://moodle.org/user/view.php?id=13727&course=5 Martin Langhoff]

For further details see:
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=119670 gsoc: what you paint is what you get] forum discussion
* http://wiki.laptop.org/go/XS_Moodle_design#What_You_Paint_Is_What_You_Get_editor
* Tracker issue MDL-18651

==Blog-style course format==

Course formats drive the main page in Moodle -- the course page. The existing course formats assume that the teacher has everthing planned ahead of time, and that the course fits in one page. Primary teachers live in a different world -- they prepare each day no more than a few days beforehand, and their course is a year long. A blog-style format can make their life much much simpler.

:'''Skills required''': PHP
:'''Difficulty level''': Medium-low
:'''Mentors''': [http://moodle.org/user/view.php?id=13727&course=5 Martin Langhoff]

For further details see:
* Tracker issue MDL-18652

==See also==

* [[GSOC]] - describing Moodle's involvement with Google in their Summer of Code program
* [[Talk:Projects for new developers]] for 2008 project ideas which have not yet been implemented
* [[Development:Usability/Improve Moodle User Experience Consistency]]

[[Category:GSOC]]

Development:Weekly Code Review

2009-03-23T14:37:49Z

Poltawski: /* Every Tuesday */

Moodle has a weekly process of code review in the stable branches to help improve the quality of stable packages and to help detect any regressions that may have occurred in stable code.

Here is the process for testers and developers:

==Every Tuesday==

===Don't check any new fixes into CVS===

HEAD is OK, but please avoid new fixes in all STABLE branches unless they are definitely definitely not going to cause new bugs ;-)

===Find bugs to test===

All developers and testers should be looking at:

Moodle 1.9 stable: [http://tracker.moodle.org/secure/IssueNavigator.jspa?mode=hide&requestId=10565 1.9.x Needs QA review]

(Make sure you can see the QA Assigned column)

Grab any bug that:

* Is from the last week
* You did not fix
* Does not have a QA assignee yet

and claim it by editing the bug to add your name as QA Assignee.

===Test the fix===

* Read the comments
* Look at the patch attached to the tracker
* Try the feature out to make sure it works as advertised
** Ensure you have debugging set to the DEBUG_DEVELOPER & look for new errors
** Test for potential regressions in other areas the fix may affect
* Post new comments (or talk on Moodle HQ) if you need clarification

===Deal with any problems===

* Post a comment on the bug with details (preferably including patch!)
* Reopen the bug
* If it looks like the original developer isn't seeing it, reassign to Eloy Lafuente for [[Development:Bug triage|triage]]
* If the fix is obvious and you have CVS access, fix it yourself

===Mark the fix as reviewed===

* When you are satisfied the bug is correctly fixed, simply change the status from Resolved to Closed
* If you committed any fix, let somebody else review it again - do not Close it yourself

==Every Wednesday==

* The download site will automatically tag the whole current stable codebase (e.g. MOODLE_19_WEEKLY) at 1:00 GMT on Wednesday morning and then build download packages

==See also==

*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=93474 Tuesday Code Reviews] forum discussion

[[Category:Developer|Weekly Code Review]]
[[Category:Quality Assurance]]

Installations 30000 plus

2009-02-08T01:14:49Z

Poltawski: typo

{{Template:Large Installations}}

==Austria==

* Federal Ministry of Education - [http://http://www.eduhi.at/ education highway]: [http://www.edumoodle.at Free Moodle for Austrian schools.]
(02/Sept/2008)
- 3.849 courses
- 114.845 users
- 1.000+ schools
- 1 Installation

==Brazil==

* [http://aprender.unb.br Universidade de Brasília] - 34,587 users (12/20/2007)

==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 175,000 registered users across over 700 individual moodle installs provided to every school in Cumbria and Lancashire. Approximately 50,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.

Installations 30000 plus

2009-02-08T01:11:17Z

Poltawski: adding note about the CLEO install

{{Template:Large Installations}}

==Austria==

* Federal Ministry of Education - [http://http://www.eduhi.at/ education highway]: [http://www.edumoodle.at Free Moodle for Austrian schools.]
(02/Sept/2008)
- 3.849 courses
- 114.845 users
- 1.000+ schools
- 1 Installation

==Brazil==

* [http://aprender.unb.br Universidade de Brasília] - 34,587 users (12/20/2007)

==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 175,000 registered users across over 700 individual moodle installs provided for to every school in Cumbria and Lancashire. Approximately 50,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.

Development talk:Web services

2009-02-03T07:32:40Z

Poltawski:

==general remarks about OUTPUT of operations:==
Is true of false informative enough ?
Should the API have some sort of "last_error" function giving back more details such as "non existing course, non existing user, duplicate entry ...)
Shall we consider that affecting a role that already exist or removing role that do not exist as an error (output=false) or not (output=true)
:yep, agree, I'd result always one well defined $result object, with his status, error code and error msg (and perhaps, the whole original WS request encapsulated for easier debugging).
:[[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 19:55, 21 December 2007 (CST)
I agree but throught the WS we need to be be carefull with the feedback we give to errors, due to security issues. --[[User:Ludo (Marc Alier)|Ludo (Marc Alier)]] 14:14, 22 December 2007 (CST)

==some WS to be able to... build courses ?==
Perhpas it would be a great idea to start thinking about some WS functionalities like this:

* add_course, delete_course, reset_course
* add_section, delete_section, show_section, hide_section
* add_activity, delete_activity, show_activity, hide_activity

Apart from the WS utility itself: automated creation of courses... it would help (or force, as we prefer), to better encapsulate course/section/modules internals, 100% isolating the creation and configuration from the frontend (forms, WS...). It implies some decisions, like upwards compatibility of old modules (although I think it can be maintained)... and so on, you know.

Just one idea to analyse. But with benefits in the end, IMO.
[[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 20:02, 21 December 2007 (CST)

I do agree with this ; this would also allow creation of specific courses, customized for some users, depending of their "performances" in external evaluations methods ; when the ePortfolio API will be finalized in Moodle core's, accessing the portfolio of any user would be needed.
[[User:Patrick Pollet|Patrick Pollet]] 04:21, 30 December 2007 (CST)

==the problem of ID of entity to fetch:==
In the list of API calls defined in this page, Moodle entity to process (user,course,grade,event ...) is identified by an ID, that is implicitly the Moodle's internal id field used in the database. This raises a problem since it is very likely that in the "external SIS" talking to Moodle across the Web Service, the entity will be identified by another attribute such as an idNumber (user,course), a short name (course) or even an username (login of user).

So either we must provide :

* extra API calls to convert external identifiers to Moodle's internal id, such as user_id_from_idnumber, user_id_from_username, course_id_from_shortname ..., at the cost of extra calls before the real one ; three calls would be needed to enrol student "CS2121212", to course "JAVA_101".

* extra API functions such as delete_user_byusername, get_course_by_idnumber , enrol_student_byidnumber_tocourse_byshortname ....

* or add parameters to the current API calls specifiying what identifier we are using such as delete_user(id,idField) with idField being a string that could be "id","idnumber","username","email" ... or enrol_student(sid,"idnumber",cid,"shortname") . This is the approach in the current SOAP implementation (with some calls of the previous type (get_user_byusername()...)

[[User:Patrick Pollet|Patrick Pollet]] 04:21, 30 December 2007 (CST)

== output of operations: adding URLs?==
In addition, I suggest to return the full URL towards every Moodle entity, either added or got.
* user added with id 12345 --> http://moodle.xxx.edu/user/view.php?id=12345&course=1
* got user 12345 --> http://moodle.xxx.edu/user/view.php?id=12345&course=1
* course added with id 67 --> http://moodle.xxx.edu/course/view.php?id=67
* got course 67 --> http://moodle.xxx.edu/course/view.php?id=67
* etc.

Today, in my uPortal installation, I request for Moodle database and display a list of courses in which the connected user is enrolled. Of course I provide links to these courses so that he can directly access. In addition I display a list of the last changes in these courses, again with links to the resources/activities.

If the URLs are returned by the WS then the calling service has nothing to know about Moodle URLs. Else it has to build every URL by aggregating Moodle alias + adequate PHP script + entity ID

== Implementation feedback ==

[Feedback]
Speaking as someone who will be using this API to integrate with another line of business application I would recommend the following changes.

The add_user method should really be a 'SetUser' ie it will create the record if it does not exist or update it it if it does. The ID that is passed into the method would be *our* primary key which Moodle would use to recognise the user record within Moodle. We would not normally need to know anything about the Moodle primary key.

One option to make the web services maintainable is to accept XML as a parameter and not a structure or custom object. That way you can define an XSD which will define required\optional parameters. Equally if you include a version number you can change the XML to add new features without having to redefine the web service signature itself (and hence clients will not have to recompile their code). So you may receive a SetUser call with XML V1.0 and another with XML V2.0 on the same webservice but from two different clients supporting different versions of the API.

The method *must* accept an array of users - it's a little trickier to set this up in the client code but is much more scalable (if there's some good sample code then this is easier anyway). The latency (round trip time) with web service calls is high so you want to do as much as you can in a single call. We have a customer who wants us to deploy Moodle to 40,000 users - we're not going to do that using individual calls.

Would it be possible to expand on the existing web service work rather than produce something completely new? We're investing a lot of effort with these services and we wouldn't like to have to re-do that work.
[/Feedback]

== Using web services to allow client side code such as js, Flash/Flex or java to communicate with Moodle ==

I understand these web services should also allow client side code to communicate with Moodle.

I imagined that web services used by client side code should be authenticated with a 'session key'. When the server outputs a page with such an object in it then a random session key string should be created and passed into the client side code through the html that embeds/outputs the object in a page. I think the session key should be associated with a user and probably a Moodle context. Then the context can be used within block related code or activity module related code to know when for example the client side code passes a log message back to Moodle or when it passes a grade back to Moodle that the grade is for such and such an activity. For web services for Flash I thought an appropriate way to do this would be to have an array of objects of session keys and there associated context/other data in the $SESSION object.

== Config settings ==

This are the main switches / global config settings to control what's available:

* WS Global switch:
** Check for global$CFG->enablewebservices properly (outer layer).
* WS Capability:
** Create the 'moodle/site:use webservices' capability and check for it in medium layer globally (after auth). Default to admin role only.
* WS Protocol/Function switches:
** Create new setting $CFG->enabledwsprotocols, with list of enabled protocols (default to none) and check request against that (outer layer)
** Create new setting $CFG->enabledwsfunctions, with list of enabled functions (default to none) and check request against that (on function invocation)
* WS Function capabilities?? Not sure (overlay with normal capabilities). -1
* Other restrictions (fixed list of users, IP, SSL required...)
[[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 08:44, 27 January 2009 (CST)

== IP restriction ==

We'd like a feature to restrict web services to a list of specified IP addresses for additional security. On our services we just have like this:

$allowedaddresses=preg_split('/[,\s]+/',$CFG->privilegedserverips,-1,PREG_SPLIT_NO_EMPTY);
if(!in_array($_SERVER['REMOTE_ADDR'],$allowedaddresses,true)) {
error('You are not permitted to access this page.');
}

(note I think REMOTE_ADDR may not be reliable on all systems? eh whatever)

so we use a comma-separated list of IP addresses that are permitted. Something similar would be good for this.

Maybe it should really go into the user section ie a way to restrict a specific user to given IPs? Of course ideally it would then support ranges/wildcards as well, etc, but then it becomes a lot of work instead of a simple option to the webservice stuff...

[[User:sam marshall|sam marshall]] 08:52, 27 January 2009 (CST)

:There is already a nice address_in_subnet function in lib/moodlelib.php, which gives you a flexible way to check IP addresses. Normally used in combination with getremoteaddr(), also in moodlelib.--[[User:Tim Hunt|Tim Hunt]] 20:40, 27 January 2009 (CST)

== Why the Auth Plugin? ==
Just curious what I missed - what was the reason for implementing a web services auth plugin? I agree with what Eloy said in chat - the problem with this approach is that you'd probably want to apply any restrictions that might be implemented in the plugin to be applied to users with traditional authentication? --[[User:Dan Poltawski|Dan Poltawski]] 01:32, 3 February 2009 (CST)

Development:MNet

2009-02-02T22:42:57Z

Poltawski: fix definiton of is_mnet_remote_user (following on from MDL-18118)

{{Moodle 1.8}}

Random notes for Moodle Network. Should get these organised...

* Documentation for administrators is here [[Moodle Network]]
* Some old documentation about the initial planning and dev
** [[Community_hub]]
** [[Community_hub_technotes]]
** [[Community_hub_progress]]

=Key config variables and functions=

// what mnethostid should "local" users have?
// this is guaranteed to be set, except during the 1.7->1.8 upgrade
$id = $CFG->mnet_localhost_id;

// a quick way to check if our user is remote:
is_mnet_remote_user($user);
// internally is_mnet_remote_user() does
// if ($user->mnethostid != $CFG->mnet_localhost_id)

// Are we listening to mnet requests? Nothing else works if we aren't.
if ($CFG->mnet_dispatcher_mode === 'strict') {
// Moodle is listening to mnet requests. Nothing else works if we aren't.
}

// Are we allowing remote users in via auth/mnet?
if (is_enabled_auth('mnet')) {
// yes indeed
}

// Will auth/mnet autocreate new user accts?
if (get_config('auth/mnet', 'auto_add_remote_users')) {
// yes it will!
}

=Protocols=

==MNET handshake==

==Authentication/SSO==

==Enrolment==

=To Do=

Some immediate items that would add polish without major surgery

* Exchange more enrolment info at log-entry exchange time on cron
* Special default role
** Add a new "remote student" role
** Add a config var to enrol/mnet: "defaultremoterole" to use "remote student"
** Add a config var to the courses table to optionally override defaultremoterole
* Nicer CSS in the "my courses" listing in moodle homepage for remote hosts and remote courses. See course/lib.php print_remote_course() and print_remote_host().

=Roadmap=

A bit more work, and a whole lot more features. From easy to hard...

* Better per-host stats and log views for administrators. This is relatively easy using data we already have.
* In mod/forum craft a special URL for remote users so that the post URL is in the wantsurl parameter, so they can bounce-off their IDP in one go.
** According to Jonathan Harker, this requires that we modify jump to accept the remote wwwroot as a parameter. Also: will this be safe enough?
* Display aggregated calendar on the IDP
* Exchange grades. Needs a bit of design.
* Build a SCORM/IMSCP/MoodleZip repository scheme.
** MartinL has some ideas on how to get this done in easy and super-scalable.

[[Category:Developer|Moodle Network]]
[[Category:MNET]]

Site-wide groups

2009-01-21T12:42:02Z

Poltawski: /* Explaining why we need site-wide groups for enrolment purposes (Dan Poltawski) */

== Explaining why we need site-wide groups for enrolment purposes (Dan Poltawski) ==

In my experience the need for site wide groups has not been entirely clear to developers, especially unclear is why existing enrolment plugins are not sufficient for schools (K12/primary/secondary), especially when compared to higher education. I developed the [http://moodle.org/mod/data/view.php?d=13&rid=1585&filter=1 CLEO MIS Tool] as a stop-gap solution to address some of the deficiencies and this has been very popular. I'm convinced of the need for 'a solution' so I will try and explain the reasons here.

===Dans Example Simplified school ===

====Components====
* School Moodle
** Maintained by teachers or curriculum support staff
** Rapidly changing
** Course design can vary across schools/ departments/ teaching staff

* MIS (student information) System
** Contains student details, class lists etc
** Maintained by school administrative staff
** Relatively static and standardised, used to generate reports, timetables etc
** Often contains ''imperfect'' data

* Relevant to both - don't typically have sophisticated technical support to craft data to integrate both

====Existing Solutions====

* Use an enrolment plugin to generate enrolments from MIS System
** Requires a class group from MIS to map directly to a course
** A moodle course has to be created for every single physical class (not how it works practically- nightmare for teachers)
** The 'course design' to be consistent across school (One teacher might create a single moodle course for all her physical classes, another might created one moodle course shared across classes and other variations).
** 'The power' to do stuff is in the teachers hands - largely automatic rather than teacher choosing who they wish in each course

* Manual Enrolment (This is typically how many many schools use moodle)
** Teacher assigns every user from the complete list (1000+) of users one at a time
** If using groups mode in the course, picks these out individually too
** Massive time hog

* CLEO MIS Tool
** Good
*** Populates 'class groups' (separate db table -unrelated to core stuff) from MIS system via csv import
*** At role assignment time, teacher can select a MIS class group from list and assign all users in group at once (rather than stuednt at a time)
*** Can assign multiple class groups to one course, or any variation
*** Power is in the teachers hands how to organise
*** MIS Grouped enrolment at any role-assignment point
** Bad
*** Intentionally dumb: simply selects the users who are present in a mis group at a specific time and enrols them, changes in MIS groups are not reflected in role assignments over time
*** Doesn't create course level groups in moodle

====The Dream Solution====
* MIS System populates 'global groups' data
* Global groups can be populated by multiple plugins (extension to existing enrolment plugins?)
* Teacher can assign any number of global groups to a course - these can also populate course groups (for separate groups mode etc)
* Changes in MIS data reflected in course enrolments (At least for users added)

--[[User:Dan Poltawski|Dan Poltawski]] 06:32, 21 January 2009 (CST)

Site-wide groups

2009-01-21T12:34:51Z

Poltawski: fixing typos

== Explaining why we need site-wide groups for enrolment purposes (Dan Poltawski) ==

In my experience the need for site wide groups has not been entirely clear to developers, especially unclear is why existing enrolment plugins are not sufficient, especially when compared to higher education. I developed the [http://moodle.org/mod/data/view.php?d=13&rid=1585&filter=1 CLEO MIS Tool] as a stop-gap solution to address some of the deficiencies and this has been very popular. I'm convinced of the need for 'a solution' so I will try and explain the reasons here.

===Dans Example Simplified school ===

====Components====
* School Moodle
** Maintained by teachers or curriculum support staff
** Rapidly changing
** Course design can vary across schools/ departments/ teaching staff

* MIS (student information) System
** Contains student details, class lists etc
** Maintained by school administrative staff
** Relatively static and standardised, used to generate reports, timetables etc
** Often contains ''imperfect'' data

* Relevant to both - don't typically have sophisticated technical support to craft data to integrate both

====Existing Solutions====

* Use an enrolment plugin to generate enrolments from MIS System
** Requires a class group from MIS to map directly to a course
** A moodle course has to be created for every single physical class (not how it works practically- nightmare for teachers)
** The 'course design' to be consistent across school (One teacher might create a single moodle course for all her physical classes, another might created one moodle course shared across classes and other variations).
** 'The power' to do stuff is in the teachers hands - largely automatic rather than teacher choosing who they wish in each course

* Manual Enrolment (This is typically how many many schools use moodle)
** Teacher assigns every user from the complete list (1000+) of users one at a time
** If using groups mode in the course, picks these out individually too
** Massive time hog

* CLEO MIS Tool
** Good
*** Populates 'class groups' (separate db table -unrelated to core stuff) from MIS system via csv import
*** At role assignment time, teacher can select a MIS class group from list and assign all users in group at once (rather than stuednt at a time)
*** Can assign multiple class groups to one course, or any variation
*** Power is in the teachers hands how to organise
*** MIS Grouped enrolment at any role-assignment point
** Bad
*** Intentionally dumb: simply selects the users who are present in a mis group at a specific time and enrols them, changes in MIS groups are not reflected in role assignments over time
*** Doesn't create course level groups in moodle

====The Dream Solution====
* MIS System populates 'global groups' data
* Global groups can be populated by multiple plugins (extension to existing enrolment plugins?)
* Teacher can assign any number of global groups to a course - these can also populate course groups (for separate groups mode etc)
* Changes in MIS data reflected in course enrolments (At least for users added)

--[[User:Dan Poltawski|Dan Poltawski]] 06:32, 21 January 2009 (CST)

Site-wide groups

2009-01-21T12:32:31Z

Poltawski: Tried to add the details fleshing out the need for 'group based enrollment'

== Explaining why we need site-wide groups for enrolment purposes (Dan Poltawski) ==

In my experience the need for site wide groups has not been entirely clear to developers, especially unclear is why existing enrolment plugins are not sufficient, especially when compared to higher education. I developed the [http://moodle.org/mod/data/view.php?d=13&rid=1585&filter=1 CLEO MIS Tool] as a stop-gap solution to address some of the deficiencies and this has been very popular. I'm convinced of the need for 'a solution' so I will try and explain the reasons here.

===Dans Example Simplified school ===

====Components====
* School Moodle
** Maintained by teachers or curriculum support staff
** Rapidly changing
** Course design can vary across schools/ departments/ teaching staff

* MIS (student information) System
** Contains student details, class lists etc
** Maintained by school administrative staff
** Relatively static and standardised, used to generate reports, timetables etc
** Often contains ''imperfect'' data

* Relevant to both - don't typically have sophisticated technical support to craft data to integrate both

====Existing Solutions====

* Use an enrolment plugin to generate enrolments from MIS System
** Requires a class group from MIS to map directly to a course
** A moodle course has to be created for every single physical class (not how it works practically- nightmare for teachers)
** The 'course design' to be consistent across school (One teacher might create a single moodle course for all her physical classes, another might created one moodle course shared across classes and other variations).
** 'The power' to do stuff is in the techers hands - largely automatic rather than teacher chosing who they wish in each course

* Manual Enrolment (This is typically how many many schools use moodle)
** Teacher assigns every user from the complete list (1000+) of users one at a time
** If using groups mode in the course, picks these out individually too
** Massive time hog

* CLEO MIS Tool
** Good
*** Populates 'class groups' (seperate db table -unrelated to core stuff) from MIS system via csv import
*** At role assignment time, teacher can select a MIS class group from list and assign all users in group at once (rather than stuednt at a time)
*** Can assign multiple class groups to one course, or any variation
*** Power is in the teachers hands how to organise
*** MIS Grouped enrollment at any role-assignment point
** Bad
*** Intentionally dumb: simply selects the users who are present in a mis group at a specific time and enrols them, changes in MIS groups are not reflected in role assigments over time
*** Doesn't create course level groups in moodle

====The Dream Solution====
* MIS System populates 'global groups' data
* Global groups can be populated by multiple plugins (extension to existing enrolment plugins?)
* Teacher can assign any number of global groups to a course - these can also populate course groups (for seperate groups mode etc)
* Changes in MIS data reflected in course enrolments (At least for users added)

--[[User:Dan Poltawski|Dan Poltawski]] 06:32, 21 January 2009 (CST)

Development talk:Plugin types

2009-01-06T11:11:00Z

Poltawski: New page: Not looked at them at all (not added to list as I don't know about them) - but I think this page is missing newly added messaging plugin types --~~~~

Not looked at them at all (not added to list as I don't know about them) - but I think this page is missing newly added messaging plugin types --[[User:Dan Poltawski|Dan Poltawski]] 05:11, 6 January 2009 (CST)

Development:Local customisation

2008-12-18T17:51:54Z

Poltawski: Added info about workaround for an install.xml file

== Disclaimer ==

Some of these entries are things that Penny has patches for and has not yet committed, and are under discussion. The meta bug for all these items is here: http://tracker.moodle.org/browse/MDL-17376

== General customisations ==

Moodle has been designed with extensibility in mind. There are many plug-in points available though out Moodle to allow developers add new functionality to Moodle without modifying core code.

See the [[Developer_documentation#Make_a_new_plugin|make a new plugin section of the Developer documentation page]] for the different plugin types available, and documentation on how to develop for them.

== local/ folder for 'hacky' customisations ==

Sometimes it is not possible to use the available plug-in points to make your change. In situations like this then the local folder is for you. The idea is that instead of scattering your changes throughout the code base, you put them all in a folder called 'local'. Using this folder means you won't have to deal with merging problems when you upgrade the rest of your Moodle installation.

The local folder has some of the plug-in points available which are available to other modules. Perhaps most useful the local/db/ folder can be used to make database schema changes and custom role permissions.

However, using the local folder should be absolutely the last resort. Long term, you will almost certainly find it easier to maintain your changes if you can package them up as one of the standard types of plugins.

=== Local database changes and version ===

If you need to make local database customisations that are not easily encapsulated by a block or module, Moodle does support the use of a local db upgrade script, and local version number.

This is almost exactly the same as every other db/upgrade.php and version.php except for the following points:

==== local/version.php ====

local/version.php must look like:

<code php>
$local_version = 2008121700;
</code>

==== local/db/install.xml ====

Local/ has no install.xml - only an upgrade.php. This is because often the changes that you want to make are not full tables, but just extra columns, and a local install.xml makes less sense than just upgrade.php.

If you would like to create tables using using an install.xml this can be achieved by putting something like that this in your upgrade.php file:

<code php>
$result = install_from_xmldb_file(dirname(__FILE__).'/install.xml');
</code>

==== local/db/upgrade.php ====

local/db/upgrade.php must look like:

<code php>
function xmldb_local_upgrade($oldversion) {
global $CFG, $db;

$result = true;

if ($result && $result < 2008121700) {
$result = $result && create_table($table);
}
return $result;
}
</code>

=== Local post-installation data insertion ===

In discussion - see http://tracker.moodle.org/browse/MDL-17440

=== Local capabilities ===

Just like core and modules, Moodle supports the use of a db/access.php inside local/ to define local capabilities.

The formatting is exactly the same as the other db/access.php scripts - an array keyed by capability name, containing arrays of capability data, like so:

<code php>
$local_capabilities = array(
'moodle/local:capability' => array(
'captype' => 'write',
'contextlevel' => CONTEXT_SYSTEM,
'riskbitmask' => RISK_SPAM,
),

</code>

Note that for all local capabilities you add, you'll need to add language strings.
Moodle will expect to find them in local/lang/en_utf8/local.php (eg for English)
with a key (following the above example) of local:capability

=== Local event subscriptions ===

''' Pending commit '''

It is often very helpful to be able to write custom code that subscribes to normal events that Moodle throws. It's also handy to be able to throw and catch your own custom events, as the Event API provides a very handy mechanism to do signal handling.

Local event handlers get registered at install/upgrade time just as the event handlers for modules do. To trigger an update when you add a new event handler, you must bump the local version number.

Event handlers must be defined in an array, keyed by event name, with each entry in the array information about the handler, like so:

<code php>
$handlers = array(
'some_core_event' => array( // eg 'user_created'
'handlerfile' => '/local/lib.php', // example
'handlerfunction' => 'local_user_create_handler',
'schedule' => 'cron'
)
);
</code>

=== Local admin menu items and settings ===

You can add extra configuration items to Moodle by creating a file, local/settings.php which accesses the $ADMIN variable directly and adds new items to it. This will make them appear in the site administration block on the homepage, and create the config options that administrators can change. You can also add whole new custom config pages (admin_externalpage). For example:

<code php>

$ADMIN->add('root', new admin_category($name, $title);
$ADMIN->add('foo', new admin_externalpage($name, $title, $url, $cap);

</code>

=== Local backup and restore hooks ===

In discussion - see http://tracker.moodle.org/browse/MDL-17444

=== Local course deletion hook ===

This is due to be removed, and replaced with an event.

Previously, when you emptied ('''not deleted''') a course, the notify_local_course_delete method was called, which looked for a local_delete_course method in local/lib.php. The naming of this is a little ambiguous because the course is being emptied, not deleted.

Going forwards, we aim to have two events - course_emptied and course_deleted. Support for the local_delete_course method will be removed.

See http://tracker.moodle.org/browse/MDL-17445 for more info.

=== Local my moodle overrides ===

('''pending commit''')

By default, the My Moodle page shows a course overview in the center column. Some sites might want to replace that with some custom code, or even just some static content. This is very easily accomplished by:

* Creating a local/lib.php
* Putting a function in there, called local_my_moodle.

This function will be called '''instead of'' (rather than in addition to), the default center column.

=== Local stickyblocks targets ===

('''pending commit''')

In the case where you're developing a heavily customised site, it might happen that you develop a pagetype that has the ability for people to add blocks to. In this case, you might want to also make it stickyblock enabled.

This is easily achieved by:

* Create local/lib.php
* Create a method in there called local_get_sticky_pagetypes that returns an array just like the $pagetypes array at the top of admin/stickyblocks.php.

For example:

<code php>

function local_get_sticky_pagetypes() {
return array(
'custom_pagetype' => array(
'id' => 'custom_pagetype',
'lib' => '/local/lib.php',
'name' => get_string('custom_pagetype', 'local')
)
);
}

</code>

You then must create a page that extends page_base. Don't forget that if your pagetype is stickyblock enabled, it needs to take this into account in some of its methods. For example:

<code php>

class custom_pagetype extends page_base {

// normal page type class

function url_get_path() {
global $CFG;
if (defined('ADMIN_STICKYBLOCKS')) { // admin is editing stickyblocks, not a normal page
return $CFG->wwwroot . '/admin/stickyblocks.php';
}
return '';
}

function url_get_parameters() {
global $CFG;
if (defined('ADMIN_STICKYBLOCKS')) {
return array('pt' => 'custom_pagetype');
}
}
}
</code>

and map it with page_map_class:

<code php>
page_map_class('custom_pagetype', 'custom_pagetype');
</code>

=== Local user profile view hook ===

('''pending commit''')

Sometimes, it may be desirable to do something like add extra buttons to the bottom of the user's profile page - if you've developed some custom code to perform extra actions on a user, for example. This is very easy to do.

* Create local/lib.php
* Create a function in there, local_user_view.

<code php>

function local_user_view($user, $course) {

// capability check

// extra stuff

}

</code>

=== Local language strings ===

The only place in the above list that requires an additional language file is the local capabilites. These are expected to be in lang/$lang/local.php and keyed with local:capname.

Additionally, you can of course add lang/$lang/local.php just like an extra language file and call it with the usual get_string('key', 'local', $a) syntax.

There is also the ability to create a special custom lang/{$lang}_local/ directory (eg lang/en_utf8_local/), which contains just the strings that you want to override from the main language pack. Moodle will always look there '''first''' before finding the strings in the normal language pack.

This is because, historically, people have wanted to override some strings, typically things like 'course' to become 'module', or similar, and have created custom language packs. But then this forces the users to have this custom pack selected. The use of {$lang}_local is much more lightweight.

==See also==

*[http://cvs.moodle.org/moodle/lib/locallib.php?view=markup CVS:moodle/lib/locallib.php]
*Using Moodle [http://moodle.org/mod/forum/discuss.php?d=86903 Local Customisations] forum discussion

[[Category:Developer|Local customisation]]

Development:How to apply a patch

2008-12-11T13:48:58Z

Poltawski: /* Dealing with potential problems */

==Introduction==
This page explains how you can apply a patch file. Patch is a standard format, and there are many options for how to apply one. Pick the one that is easiest for you.

Perhaps most critical is the usage of the -p flag, which tells patch about the relationship between the directory where the patch file is located and the files that will be patched. See the references below for details and DO NOT assume anything.

==Apply a Patch in Windows using [http://gnuwin32.sourceforge.net/packages/patch.htm gnuwin32]==

* Download and extract patch for windows from [http://gnuwin32.sourceforge.net/packages/patch.htm sourceforge] I placed the patch.exe binary in C:\bin

* Download and extract Moodle somewhere. eg: C:\moodle

* Download the patch file and place it in the same directory you put Moodle (C:\moodle\password-policy-17.diff)

* Open the patch file with Wordpad, and click 'File' >> 'Save as...', choose a different name for the file eg ('mynewpatch.diff') and "Save as type" >> 'Text Document - MS-DOS Format'

* Open up a command text window, and type:

cd \moodle
c:\bin\patch.exe --dry-run -p1 < mynewpatch.diff

:The number after <tt>'-p'</tt> option can vary depending on the patch file, as it depends on the way the patch file was generated. Have a look at the [http://www.rt.com/man/patch.1.html 'patch' utility manual page ] to see how the <tt>'-p'</tt> option works. You could also have a look at this [http://www.linuxtutorialblog.com/post/introduction-using-diff-and-patch-tutorial diff and patch tutorial].
* You should get an output similar to this (the names and quantity of patched files vary from patch to patch):

patching file admin/settings/security.php
patching file lang/en_utf8/admin.php
patching file lib/moodlelib.php
patching file login/change_password.php
patching file login/signup.php
patching file user/edit.php
Hunk #1 succeeded at 430 (offset 2 lines).

:At this stage the patch has not been applied. We just simulated the application (with the <tt>'--dry-run'</tt> option), to see if we are going to find any problems with it. Before explaining how to actually apply the patch, we are going to talk about what could be wrong, and how to deal with it.

===Potential problems and how to deal with them===
====Potential problems====
If everything goes well, the patch will apply cleanly and life should be good! But sometimes the patch will not apply 100% cleanly due to a version mismatch between the original files used to produce the patch file and your local files. In this case, the 'patch' command will try to apply as many changes as it can, and will emit some diagnostics describing the problems it encounters.

* If you get any <tt>'Hunk #n succeeded...'</tt> messages, the patch would have been applied correctly although at different line numbers than the original file. If we had actually applied the patch, the 'patch' command would have created an additional file for each of the files where the hunk was applied at a different offset, that would be named like the original file with the additional extension <tt>.orig</tt>.

* If you get any <tt>'Hunk #n failed...'</tt> messages, the patch would have not applied correctly. In this case the 'patch' command would have created two additional files for each of the files where the hunk was not applied correctly, called:
** <tt>original-file-name.orig</tt>    This would be the original file before the patch was applied, just like above.
** <tt>original-file-name.rej </tt>    This file would contain the hunks that could not be applied correctly, so you could inspect them.

====Dealing with potential problems====
Dealing with the first problem (the offsetted hunks) is trivial: we just need to delete the .orig files once we actually apply the patch.

In the second case (failed hunks), unless you know how to fix the failed hunks by hand, you should not apply the patch, as that would corrupt your Moodle install. If you want to apply the patch and try to fix the failed hunks by hand, you should use the <tt>'-b'</tt> option. That option automatically makes a backup of every file the patch applies to, with the <tt>.orig</tt> extension. That would allow you go back to the original files state by simply overwritting the modified files with their <tt>.orig</tt> backups.

Sometimes, there will be a large difference in line numbers since a patch was generated and the patch will not apply. You can tell patch allow larger differences in line numbers by using the fuzz option '-F' to increase the number of lines difference there can be. For example patch -F 100 would allow 100 lines difference.

===Actually applying the patch===
Now that we know what could go wrong and how to deal with it, let's see how to apply the patch. We only need to remove the <tt>'--dry-run'</tt>:

cd \moodle
c:\bin\patch.exe -p1 < mynewpatch.diff

and optionally use the <tt>'-b'</tt> option if we are going to try to fix the failed hunks by hand:

cd \moodle
c:\bin\patch.exe -b -p1 < mynewpatch.diff

==Apply a Patch in Linux using "patch"==
use something like:
patch -p1 < patchfile.diff
see [http://linux.about.com/od/commands/l/blcmdl1_patch.htm here] for more details on using Patch in Linux

==See Also==

* [[Patch]]
* [[Development:How_to_create_a_patch]]
* [http://drupal.org/node/32875 Drupal - using Cygwin in Windows to apply a patch]
* [http://drupal.org/node/60818 Drupal - how to apply a patch in Mac OS X]
* [http://moodle.org/mod/forum/discuss.php?d=61379#p286372 moodle post - using gnuwin32 to apply a patch]

[[Category:Developer]]

Development:How to apply a patch

2008-12-11T13:48:34Z

Poltawski: quick note about the fuzz option

==Introduction==
This page explains how you can apply a patch file. Patch is a standard format, and there are many options for how to apply one. Pick the one that is easiest for you.

Perhaps most critical is the usage of the -p flag, which tells patch about the relationship between the directory where the patch file is located and the files that will be patched. See the references below for details and DO NOT assume anything.

==Apply a Patch in Windows using [http://gnuwin32.sourceforge.net/packages/patch.htm gnuwin32]==

* Download and extract patch for windows from [http://gnuwin32.sourceforge.net/packages/patch.htm sourceforge] I placed the patch.exe binary in C:\bin

* Download and extract Moodle somewhere. eg: C:\moodle

* Download the patch file and place it in the same directory you put Moodle (C:\moodle\password-policy-17.diff)

* Open the patch file with Wordpad, and click 'File' >> 'Save as...', choose a different name for the file eg ('mynewpatch.diff') and "Save as type" >> 'Text Document - MS-DOS Format'

* Open up a command text window, and type:

cd \moodle
c:\bin\patch.exe --dry-run -p1 < mynewpatch.diff

:The number after <tt>'-p'</tt> option can vary depending on the patch file, as it depends on the way the patch file was generated. Have a look at the [http://www.rt.com/man/patch.1.html 'patch' utility manual page ] to see how the <tt>'-p'</tt> option works. You could also have a look at this [http://www.linuxtutorialblog.com/post/introduction-using-diff-and-patch-tutorial diff and patch tutorial].
* You should get an output similar to this (the names and quantity of patched files vary from patch to patch):

patching file admin/settings/security.php
patching file lang/en_utf8/admin.php
patching file lib/moodlelib.php
patching file login/change_password.php
patching file login/signup.php
patching file user/edit.php
Hunk #1 succeeded at 430 (offset 2 lines).

:At this stage the patch has not been applied. We just simulated the application (with the <tt>'--dry-run'</tt> option), to see if we are going to find any problems with it. Before explaining how to actually apply the patch, we are going to talk about what could be wrong, and how to deal with it.

===Potential problems and how to deal with them===
====Potential problems====
If everything goes well, the patch will apply cleanly and life should be good! But sometimes the patch will not apply 100% cleanly due to a version mismatch between the original files used to produce the patch file and your local files. In this case, the 'patch' command will try to apply as many changes as it can, and will emit some diagnostics describing the problems it encounters.

* If you get any <tt>'Hunk #n succeeded...'</tt> messages, the patch would have been applied correctly although at different line numbers than the original file. If we had actually applied the patch, the 'patch' command would have created an additional file for each of the files where the hunk was applied at a different offset, that would be named like the original file with the additional extension <tt>.orig</tt>.

* If you get any <tt>'Hunk #n failed...'</tt> messages, the patch would have not applied correctly. In this case the 'patch' command would have created two additional files for each of the files where the hunk was not applied correctly, called:
** <tt>original-file-name.orig</tt>    This would be the original file before the patch was applied, just like above.
** <tt>original-file-name.rej </tt>    This file would contain the hunks that could not be applied correctly, so you could inspect them.

====Dealing with potential problems====
Dealing with the first problem (the offsetted hunks) is trivial: we just need to delete the .orig files once we actually apply the patch.

In the second case (failed hunks), unless you know how to fix the failed hunks by hand, you should not apply the patch, as that would corrupt your Moodle install. If you want to apply the patch and try to fix the failed hunks by hand, you should use the <tt>'-b'</tt> option. That option automatically makes a backup of every file the patch applies to, with the <tt>.orig</tt> extension. That would allow you go back to the original files state by simply overwritting the modified files with their <tt>.orig</tt> backups.

Sometimes, there will be a large difference in line numbers since a patch was generated and the patch will not apply. You can tell patch allow larger differences in line numbers by using the fuzz option to increase the number of lines difference there can be. For example patch -F 100 would allow 100 lines difference.

===Actually applying the patch===
Now that we know what could go wrong and how to deal with it, let's see how to apply the patch. We only need to remove the <tt>'--dry-run'</tt>:

cd \moodle
c:\bin\patch.exe -p1 < mynewpatch.diff

and optionally use the <tt>'-b'</tt> option if we are going to try to fix the failed hunks by hand:

cd \moodle
c:\bin\patch.exe -b -p1 < mynewpatch.diff

==Apply a Patch in Linux using "patch"==
use something like:
patch -p1 < patchfile.diff
see [http://linux.about.com/od/commands/l/blcmdl1_patch.htm here] for more details on using Patch in Linux

==See Also==

* [[Patch]]
* [[Development:How_to_create_a_patch]]
* [http://drupal.org/node/32875 Drupal - using Cygwin in Windows to apply a patch]
* [http://drupal.org/node/60818 Drupal - how to apply a patch in Mac OS X]
* [http://moodle.org/mod/forum/discuss.php?d=61379#p286372 moodle post - using gnuwin32 to apply a patch]

[[Category:Developer]]

Development:Git tips

2008-10-02T12:58:23Z

Poltawski: added work in progress note

{{Work in progress}}
Many developers find git a useful tool to help them with moodle development, here some tips and workflows can be shared to help others.

== Thorough Resolved Bug QA review with git ==

The power of having fast access to all of moodle commit history means we can search and checkout any point in moodle source code history which allows us to powerfully QA a bug.

Please note this workflow might not be ideal for all scenarios (for example if lots of work has been done in the same area since).

Example Workflow to QA MDL-16600:

First checkout a new branch for us to work on testing the bug in MOODLE_19_STABLE. We can delete this branch later, its less dangerous than playing any of our 'live' branches.

<pre>
$ git checkout -b QA-MDL-16600 origin/MOODLE_19_STABLE
Branch QA-MDL-16600 set up to track remote branch refs/remotes/origin/MOODLE_19_STABLE.
Switched to a new branch "QA-MDL-16600"
</pre>

Now search for any commits related to this bug fix:
<pre>
$ git log --grep='MDL-16600'
commit 1c2c8b09469ac27a3829e7267f399356a05b9810
Author: tjhunt <tjhunt>
Date: Fri Sep 26 05:49:06 2008 +0000

MDL-16600 forcedownload broken for file resources.
</pre>

In order to test that these commits fixed the bug, we will revert this commit, and then try to reproduce the reported bug:

<pre>
$ git revert -n 1c2c8b09469ac27a3829e7267f399356a05b9810
</pre>

Once we've reproduced the problem, we will reset our repository back to HEAD:
<pre>
git reset --hard HEAD
</pre>

Now if the bug is fixed, it can be closed and we can delete our branch:
<pre>
git branch -D QA-MDL-16600
</pre>

(Please add your own tips here!)

==See Also==
[[Using GIT to backup moodledata]]

[[Category:Developer|Git tips]]
[[Category:Developer tools]]

Development:Git tips

2008-10-02T12:47:19Z

Poltawski: developer tools category

Many developers find git a useful tool to help them with moodle development, here some tips and workflows can be shared to help others.

== Thorough Resolved Bug QA review with git ==

The power of having fast access to all of moodle commit history means we can search and checkout any point in moodle source code history which allows us to powerfully QA a bug.

Please note this workflow might not be ideal for all scenarios (for example if lots of work has been done in the same area since).

Example Workflow to QA MDL-16600:

First checkout a new branch for us to work on testing the bug in MOODLE_19_STABLE. We can delete this branch later, its less dangerous than playing any of our 'live' branches.

<pre>
$ git checkout -b QA-MDL-16600 origin/MOODLE_19_STABLE
Branch QA-MDL-16600 set up to track remote branch refs/remotes/origin/MOODLE_19_STABLE.
Switched to a new branch "QA-MDL-16600"
</pre>

Now search for any commits related to this bug fix:
<pre>
$ git log --grep='MDL-16600'
commit 1c2c8b09469ac27a3829e7267f399356a05b9810
Author: tjhunt <tjhunt>
Date: Fri Sep 26 05:49:06 2008 +0000

MDL-16600 forcedownload broken for file resources.
</pre>

In order to test that these commits fixed the bug, we will revert this commit, and then try to reproduce the reported bug:

<pre>
$ git revert -n 1c2c8b09469ac27a3829e7267f399356a05b9810
</pre>

Once we've reproduced the problem, we will reset our repository back to HEAD:
<pre>
git reset --hard HEAD
</pre>

Now if the bug is fixed, it can be closed and we can delete our branch:
<pre>
git branch -D QA-MDL-16600
</pre>

==See Also==
[[Using GIT to backup moodledata]]

[[Category:Developer|Git tips]]
[[Category:Developer tools]]

Development:Git tips

2008-10-02T12:31:52Z

Poltawski: added seelaso

Development:Git tips

2008-10-02T12:09:17Z

Poltawski: info about deleting branch

Development:Git tips

2008-10-02T11:59:44Z

Poltawski: added a tip which allows QA

Development:Git tips

2008-10-02T11:29:38Z

Poltawski: updated cateogory

Many developers find git a useful tool to help them with moodle development, here some tips and workflows can be shared to help others.

== Streamlining Resolved Bug QA review with git ==

The power of having fast access to all of moodle commit history means we can search and checkout any point in moodle source code history which allows us to powerfully QA a bug.

Example Workflow to QA

[[Category:Developer|Git tips]]