MoodleDocs - Användarbidrag [sv]

error/moodle/nopermissiontoviewcalendar

2021-10-25T18:18:12Z

Dongsheng: Created page with "This error indicates the current user account does not have permission to view the calendar event."

This error indicates the current user account does not have permission to view the calendar event.

Användare:Dongsheng Cai

2021-08-12T00:13:06Z

Dongsheng:

= Hello =

Användare:Dongsheng Cai

2021-06-21T04:05:04Z

Dongsheng: Blanked the page

Användare:Dongsheng Cai

2021-02-24T22:49:04Z

Dongsheng:

My works:

* [http://tracker.moodle.org/secure/ViewProfile.jspa?name=dongsheng Tracker]
* [[Chats|Chat module]]
* [[Development:Repository_API|Moodle Repository API]]
* [[Development:Comments_2.0|Comments 2.0]]
* [[Development:Wiki_2.0|Wiki 2]] contributor
* [[Development:Mobile app|Moodle mobile app for iOS]]

More:
* [https://www.openhub.net/accounts/dcai/ Open Hub]
* [https://github.com/dcai My Github]
* [https://dongsheng.org My website]

Användare:Dongsheng Cai

2021-02-24T22:48:35Z

Dongsheng:

Användare:Dongsheng Cai

2017-12-03T23:36:03Z

Dongsheng:

My works:

* [http://tracker.moodle.org/secure/ViewProfile.jspa?name=dongsheng Tracker]
* [[Chats|Chat module]]
* [[Development:Repository_API|Moodle Repository API]]
* [[Development:Comments_2.0|Comments 2.0]]
* [[Development:Wiki_2.0|Wiki 2]] contributor
* [[Development:Mobile app|Moodle mobile app for iOS]]

More:
* [http://www.ohloh.net/accounts/cai Ohloh]
* [http://github.com/dongsheng My Github]
* [http://www.linkedin.com/in/dongsheng Linkedin]
* [http://dongsheng.org My website]

Mobile app Push Notifications

2014-06-30T06:54:06Z

Dongsheng:

Starting versions (1.4 ios, iPhone, iPad and 1.4.3 Android) Moodle Mobile support Push Notifications.

1. Install [https://moodle.org/plugins/view.php?plugin=message_airnotifier this plugin] in 2.4, 2.5 or 2.6* (or simply enable it in 2.7)

2. Connect it to a mesaging server, you can use ours in case your Moodle site is registered. Go to Site administration /Plugins /Message outputs /Mobile Notifications and click in Request access key

3. Users need to connect at least once with the latest version of the app to register their phones with your site.

4) Users can configure notificiations in the Moodle messaging preferences (Administration / My profile settings / Messaging)

* For Moodle versions 2.4 and 2.5 the [[Moodle Mobile additional features]] must be also installed
** Only for Moodle different to 2.7 and onwards: If you upgrade your Moodle installation, you will have to reinstall the plugin since it add a couple of functions to the core Moodle Mobile service. See https://tracker.moodle.org/browse/MDLSITE-2815?focusedCommentId=273741&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-273741 for more information

== Installing your own Notifications infrastructure ==

If you have a customized version of the Mobile app, or you want to use your own Notifications infrastructure then you have to install a private [http://airnotifier.github.io AirNotifier] (backend server for notifciations)

You have to add your app certificates there, see https://github.com/airnotifier/airnotifier/wiki/Installation

The message AirNotifier plugin allow you to point to your custom AirNotifier instance using your own access keys

Remember to install using GIT (branch moodle)

== See also ==

[[Category: Mobile]]

[[es:Mobile app Notificaciones Push]]

Mobile app Push Notifications

2014-06-30T06:53:23Z

Dongsheng:

Starting versions (1.4 ios, iPhone, iPad and 1.4.3 Android) Moodle Mobile support Push Notifications.

1. Install [https://moodle.org/plugins/view.php?plugin=message_airnotifier this plugin] in 2.4, 2.5 or 2.6* (or simply enable it in 2.7)

2. Connect it to a mesaging server, you can use ours in case your Moodle site is registered. Go to Site administration /Plugins /Message outputs /Mobile Notifications and click in Request access key

3. Users need to connect at least once with the latest version of the app to register their phones with your site.

4) Users can configure notificiations in the Moodle messaging preferences (Administration / My profile settings / Messaging)

* For Moodle versions 2.4 and 2.5 the [[Moodle Mobile additional features]] must be also installed
** Only for Moodle different to 2.7 and onwards: If you upgrade your Moodle installation, you will have to reinstall the plugin since it add a couple of functions to the core Moodle Mobile service. See https://tracker.moodle.org/browse/MDLSITE-2815?focusedCommentId=273741&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-273741 for more information

== Installing your own Notifications infrastructure ==

If you have a customized version of the Mobile app, or you want to use your own Notifications infrastructure then you have to install a private [https://github.com/airnotifier/airnotifier AirNotifier] (backend server for notifciations)

You have to add your app certificates there, see https://github.com/airnotifier/airnotifier/wiki/Installation

The message AirNotifier plugin allow you to point to your custom AirNotifier instance using your own access keys

Remember to install using GIT (branch moodle)

== See also ==

[[Category: Mobile]]

[[es:Mobile app Notificaciones Push]]

Användare:Dongsheng Cai

2012-05-03T12:31:53Z

Dongsheng:

I am Dongsheng Cai, moodle core developer.

My works:

* [http://tracker.moodle.org/secure/ViewProfile.jspa?name=dongsheng Tracker]
* [[Chats|Chat module]]
* [[Development:Repository_API|Moodle Repository API]]
* [[Development:Comments_2.0|Comments 2.0]]
* [[Development:Wiki_2.0|Wiki 2]] contributor
* [[Development:Mobile app|Moodle mobile app for iOS]]

More:
* [http://www.ohloh.net/accounts/cai Ohloh]
* [http://github.com/dongsheng My Github]
* [http://www.linkedin.com/in/dongsheng Linkedin]
* [http://dongsheng.org My website]

Användare:Dongsheng Cai

2012-05-03T12:29:30Z

Dongsheng:

I am Dongsheng Cai, moodle core developer.

My works:

* [[Chats|Chat module]]
* [[Development:Repository_API|Moodle Repository API]]
* [[Development:Comments_2.0|Comments 2.0]]
* [[Development:Wiki_2.0|Wiki 2]] contributor
* [[Development:Mobile app|Moodle mobile app for iOS]]

More:
* [http://www.ohloh.net/accounts/cai Ohloh]
* [http://github.com/dongsheng My Github]
* [http://www.linkedin.com/in/dongsheng Linkedin]
* [http://dongsheng.org My website]

Användare:Dongsheng Cai

2012-05-03T12:27:59Z

Dongsheng:

Användare:Dongsheng Cai

2012-05-03T12:27:32Z

Dongsheng:

I am a Moodle developer working at [http://moodle.com/hq/ Moodle HQ]

My works:

* [[Chats|Chat module]]
* [[Development:Repository_API|Moodle Repository API]]
* [[Development:Comments_2.0|Comments 2.0]]
* [[Development:Wiki_2.0|Wiki 2]] contributor
* [[Development:Mobile app|Moodle mobile app for iOS]]

More:
* [http://www.ohloh.net/accounts/cai Ohloh]
* [http://github.com/dongsheng My Github]
* [http://www.linkedin.com/in/dongshengc Linkedin]
* [http://dongsheng.org My website]

Användare:Dongsheng Cai

2011-05-04T12:50:01Z

Dongsheng:

I am a Moodle developer working at [http://moodle.com/hq/ Moodle HQ]

My main works with Moodle:

* [[Chats|Chat module]]
* [[Development:Repository_API|Moodle Repository API]]
* [[Development:Comments_2.0|Comments 2.0]]
* [[Development:Wiki_2.0|Wiki 2]] contributor
* [[Development:Mobile app|Moodle mobile app for iOS]]

More:
* [http://www.ohloh.net/accounts/cai Ohloh]
* [http://github.com/dongsheng My Github]
* [http://www.linkedin.com/in/dongshengc Linkedin]
* [http://dongsheng.org My website]

Comments 2.0

2011-05-04T12:14:29Z

Dongsheng: /* Moodle modules callback */

{{Moodle 2.0}}==Objectives==

The goals of comments 2.0:

* Manage comments centrally
* Use a consistent approach for all comments throughout Moodle
* Easily integrate comments 2.0 with existing modules
* Works no matter Javascript is enabled or not

==Overview==

The comments 2.0 provides APIs to:
# Add comments
# Manage comments
# Delete comments

And provides a fancy ajax interface to add/delete comments without loading a new page.

==Comments database table==

{| class="nicetable"
|-
! Field
! Type
! Default
! Info
|-
| id
| int(10)
| auto-incrementing
| The unique ID for this comment.
|-
| userid
| int(10)
|
| who wrote this comment
|-
| contextid
| int(10)
|
| The context id defined in context table - identifies the instance of plugin owning the comment.
|-
| itemid
| int(10)
|
| Some plugin specific item id (eg. forum post, blog entry or assignment submission)
|-
| commentarea
| int(10)
|
| for example, in user profile, you can comment user's description or interests, but they share the same itemid(==userid), we need comment_area to separate them
|-
| timecreated
| int(10)
|
|
|-
| timemodified
| int(10)
|
|
|-
| content
| text
|
| content of comment
|}

==Use Comments API==

===Add an option to format_text function===

Using this format_text function will add a comment icon automatically at the end of the text:

For example, using the following code in the forum module will add a comment icon to every post:

<code php>
$to = new stdclass;
$cmt->contextid = $modcontext->id;
$cmt->area = 'format_post';
$cmt->itemid = $post->id;
$options->comments = $cmt;
echo format_text($post->message, $post->messageformat, $options, $course->id)."<hr />";
</code>

===Use comment class===
To use Comments API elsewhere, using following code:
<code php>
$options->area = 'database_entry';
$options->context = $context;
$options->itemid = $record->id;
$options->showcount = true;
$comment = new comment($options);
$comment->output(false);
</code>
If you are using comments API in module context, you'd better add pluginname option, it will help comments API find callback functions faster:
<code php>
$options->area = 'database_entry';
$options->pluginname = 'data';
$options->context = $context;
$options->itemid = $record->id;
$options->component = 'mod_data';
$options->showcount = true;
$comment = new comment($options);
$comment->output(false);
</code>
==Comments API overview==

Generally speaking, only two functions you need to know to get comments 2.0 worked:
# Use comment::init to initialize comments 2.0
# Use $comment->output to display comments

The comment class has been implemented in comment/lib.php.
===class comment()===
====__construct($contextid, $comment_area, $itemid))====
Initialize class members

====init()====
It is a static function used to initialize comments, setting up languages, which must be called before html head printed

====output($return = false)====
Will print the html snippet for commenting interface, if set $return as true, it will return html string instead of printing out.

====print_comments($params = array())====
Used by non-javascript comment interface, will print a list of comments.

====add($content)====
Public instance funciton, add a comment to database, used in comment/comment_ajax.php

====count()====
Counting the number of comments

====delete($id)====
Delete a comment from database, used in comment/comment_ajax.php

====delete_comments====
Delete all comments in a specific contexts (like all comments belonging to a forum post)

==Javascript API==
Comments 2.0 implemented a YUI3 module M.core_comment to deal with the communication between browsers and moodle.
It can be found in comment/comment.js

Call M.core_comment.init will create an instance of CommentHelper class. You don't need to make any calls to this instance, it simply works out of box.

== Moodle modules callback ==
Comments API allows modules/blocks/blog to decide how comments display.

=== Data validation ===
Plugins must implement pluginname_comment_validate callback to validate comments parameters, it must return true to pass validation.

===Permission control===
Modules must implement function '''pluginname_comment_permissions''' to return post and view permission.

Blocks need to overwrite '''blockname_comment_permissions''' function of block_base.

Blog need to implement '''blog_comment_permissions''' function.

This function will return an array: array('post'=>true, 'view'=>true)

=== Check new added comment ===
The callback function allows you to change the comment content before inserting into database or reject this comment.

It takes two arguments, the comment object which contains comment details, and $params which contains context and course information.

Modules can implement a function named '''modname_comment_add'''.

Blocks need to overwrite '''blockname_comment_add''' function.

Blog need to implement '''blog_comment_add''' function.

This function should return a boolean value.

=== Filter/format comments ===
This callback allows modules check/format comments when user request to display comments.

It takes the same arguments as pluginname_comment_add

Modules can implement a function named '''pluginname_comment_display'''.

Blocks need to overwrite '''blockname_comment_display''' function.

Blog need to implement '''blog_comment_display''' function.

It will return the comment object.

=== Define a comment template ===
Modules can implement a function named '''pluginname_comment_template''', which allow modules define a comment template.
The template must have 4 embedding variables, ___id___, ___content___, ___time___, ___name___, they will be replaced with html id, comments content, comment time and commenter name

==See also==
* MDL-19118 - Comments 2.0 issue

URL downloader repository

2011-05-03T03:34:46Z

Dongsheng: Created page with "URL Downloader plugin is used to obtain resources by providing a url to webpage or file. If user provides a html web page, Moodle will parse the web page to list all images used..."

URL Downloader plugin is used to obtain resources by providing a url to webpage or file.

If user provides a html web page, Moodle will parse the web page to list all images used in web page.

If user provides a link to file, Moodle will try to download this file no matter what type it is.

Broken/id:11387

2011-04-28T06:51:47Z

Dongsheng: /* Upload and download files from moodle */

I'd love to see the ability for students to take quizzes be included in a 1.0 mobile app. Comparative LMS (BB) have not yet achieved this with their own Mobile apps and it would be a boon for mobile learning (or learning utilizing tablet devices).

== Timeframe? ==

Do we have even a ballpark estimate for when this might be available? A year would be sufficient :)

Looks great btw :)

==Obtain web service token==
In Moodle Mobile apps or other web service clients, we need a secure method to transmit token.

* The easiest way would be using https for token request script, user enter username and password, send them to HTTPS protected script to obtain the token, the disadvantage of this method is the limit of HTTP server, for some shared hosts, HTTPS is not available.
* I looked OAuth, it's getting popular, and secure. But it has a few disadvantage:
# Moodle for iPhone will support multi Moodle instances, so we have to save api and secret for each website, it's very annoying for mobile users to type such long keys
# The major problem is OAuth will need two keys: access key and access secret during transmission, then generate a signature using a few factors, the signature will embedded in http header, moodle will need to verify this signature. It looks like another security layer besides web service subsystem, if we only use it for obtaining web service token, I am not sure if worth to use it, we will have to implement OAuth server, and a few scripts to handle access keys exchange, and database tables including oauth_log, oauth_consumer (store consumer key and secret), consumer_token, access token(store access key) we need at least three new tables, probably another two to store nonce and activity logs.
* RSA algorithm can be alternative method of HTTPS, before we add a website in moodle app, we request the public key from the website, encrypt the username, password and user secret by public key, then send them to server, moodle will decrypt it by private key, if success, encrypt the key by the user secret (use 3DES or AES), 1024-2048 bits public key is considered to be safe, but it could be slow for mobile device because of the long key. ECC algorithm use shorter key and strong, but it's more difficult to implement.

My proposal would be the combination of HTTPS and RSA.

It's related to http://tracker.moodle.org/browse/MOBILE-14

--[[User:Dongsheng Cai|Dongsheng Cai]] 11:08, 20 April 2011 (WST)

==Upload and download files from moodle==
We already implemented "upload" web service, which only allow users to upload files to user private, the problem is we need to use base64 encoding binary file so it can fit into xml payload, it theoretically works, but in the real world, if we pick a file from iphone photo library, it's usually around 1.2Mb, encoding will enlarge the file by 33%, not too bad, but encoding the picture will take more than a minute, it's very bad user experience.

For better performance, we'd better use POST and GET the upload and download files, then we need to setup session, what we need to do:
# Assume user already got token, then user send token and file to a special script in Moodle, for example http://yourmoodle.com/files/ws_upload.php Moodle verify the token, if true, setup session, check permission, then allow uploading
# If users intend to download a moodle file served by pluginfile.php, first users request a special script with token, if token is valid, grant the session, then users will be able to access the files served by pluginfile.php, we need to http request in this case, if we can verify the token in pluginfile.php to reduce the http traffic, I'm not sure if it's acceptable.

It's related to http://tracker.moodle.org/browse/MOBILE-19

--[[User:Dongsheng Cai|Dongsheng Cai]] 11:08, 20 April 2011 (WST)

Broken/id:11387

2011-04-20T03:18:51Z

Dongsheng:

I'd love to see the ability for students to take quizzes be included in a 1.0 mobile app. Comparative LMS (BB) have not yet achieved this with their own Mobile apps and it would be a boon for mobile learning (or learning utilizing tablet devices).

== Timeframe? ==

Do we have even a ballpark estimate for when this might be available? A year would be sufficient :)

Looks great btw :)

==Obtain web service token==
In Moodle Mobile apps or other web service clients, we need a secure method to transmit token.

* The easiest way would be using https for token request script, user enter username and password, send them to HTTPS protected script to obtain the token, the disadvantage of this method is the limit of HTTP server, for some shared hosts, HTTPS is not available.
* I looked OAuth, it's getting popular, and secure. But it has a few disadvantage:
# Moodle for iPhone will support multi Moodle instances, so we have to save api and secret for each website, it's very annoying for mobile users to type such long keys
# The major problem is OAuth will need two keys: access key and access secret during transmission, then generate a signature using a few factors, the signature will embedded in http header, moodle will need to verify this signature. It looks like another security layer besides web service subsystem, if we only use it for obtaining web service token, I am not sure if worth to use it, we will have to implement OAuth server, and a few scripts to handle access keys exchange, and database tables including oauth_log, oauth_consumer (store consumer key and secret), consumer_token, access token(store access key) we need at least three new tables, probably another two to store nonce and activity logs.
* RSA algorithm can be alternative method of HTTPS, before we add a website in moodle app, we request the public key from the website, encrypt the username, password and user secret by public key, then send them to server, moodle will decrypt it by private key, if success, encrypt the key by the user secret (use 3DES or AES), 1024-2048 bits public key is considered to be safe, but it could be slow for mobile device because of the long key. ECC algorithm use shorter key and strong, but it's more difficult to implement.

My proposal would be the combination of HTTPS and RSA.

It's related to http://tracker.moodle.org/browse/MOBILE-14

--[[User:Dongsheng Cai|Dongsheng Cai]] 11:08, 20 April 2011 (WST)

==Upload and download files from moodle==
We already implemented "upload" web service, which only allow users to upload files to user private, the problem is we need to use base64 encoding binary file so it can fit into xml payload, it theoretically works, but in the real world, if we pick a file from iphone photo library, it's usually around 1.2Mb, encoding will enlarge the file by 33%, not bad, but encoding the picture will take more than a minute, it's very bad user experience.

For better performance, we'd better use POST and GET the upload and download files, then we need to setup session, what we need to do:
# Assume user already got token, then user send token and file to a special script in Moodle, for example http://yourmoodle.com/files/ws_upload.php Moodle verify the token, if true, setup session, check permission, then allow uploading
# If users intend to download a moodle file served by pluginfile.php, first users request a special script with token, if token is valid, grant the session, then users will be able to access the files served by pluginfile.php, we need to http request in this case, if we can verify the token in pluginfile.php to reduce the http traffic, I'm not sure if it's acceptable.

It's related to http://tracker.moodle.org/browse/MOBILE-19

--[[User:Dongsheng Cai|Dongsheng Cai]] 11:08, 20 April 2011 (WST)

Användare:Dongsheng Cai

2011-04-20T03:10:41Z

Dongsheng:

I am a Moodle developer working at [http://moodle.com/hq/ Moodle HQ]

My main works with Moodle:

* [[Chats|Chat module]]
* [[Development:Repository_API|Moodle Repository API]]
* [[Development:Comments_2.0|Comments 2.0]]
* Wiki 2 contributor
* Moodle mobile

More:
* [http://www.ohloh.net/accounts/cai Ohloh]
* [http://github.com/dongsheng My Github]
* [http://au.linkedin.com/in/dongshengc Linkedin]
* [http://dongsheng.org My website (in chinese)]

Broken/id:11387

2011-04-20T03:08:12Z

Dongsheng: /* Moodle for iPhone */

I'd love to see the ability for students to take quizzes be included in a 1.0 mobile app. Comparative LMS (BB) have not yet achieved this with their own Mobile apps and it would be a boon for mobile learning (or learning utilizing tablet devices).

== Timeframe? ==

Do we have even a ballpark estimate for when this might be available? A year would be sufficient :)

Looks great btw :)

==Obtain web service token==
In Moodle Mobile apps or other web service clients, we need a secure method to transmit token.

* The easiest way would be using https for token request script, user enter username and password, send them to HTTPS protected script to obtain the token, the disadvantage of this method is the limit of HTTP server, for some shared hosts, HTTPS is not available.
* I looked OAuth, it's getting popular, and secure. But it has a few disadvantage:
# Moodle for iPhone will support multi Moodle instances, so we have to save api and secret for each website, it's very annoying for mobile users to type such long keys
# The major problem is OAuth will need two keys: access key and access secret during transmission, then generate a signature using a few factors, the signature will embedded in http header, moodle will need to verify this signature. It looks like another security layer besides web service subsystem, if we only use it for obtaining web service token, I am not sure if worth to use it, we will have to implement OAuth server, and a few scripts to handle access keys exchange, and database tables including oauth_log, oauth_consumer (store consumer key and secret), consumer_token, access token(store access key) we need at least three new tables, probably another two to store nonce and activity logs.
* RSA algorithm can be alternative method of HTTPS, before we add a website in moodle app, we request the public key from the website, encrypt the username, password and user secret by public key, then send them to server, moodle will decrypt it by private key, if success, encrypt the key by the user secret (use 3DES or AES), 1024-2048 bits public key is considered to be safe, but it could be slow for mobile device because of the long key. ECC algorithm use shorter key and strong, but it's more difficult to implement.

My proposal would be the combination of HTTPS and RSA.

--[[User:Dongsheng Cai|Dongsheng Cai]] 11:08, 20 April 2011 (WST)

==Upload and download files from moodle==
We already implemented "upload" web service, which only allow users to upload files to user private, the problem is we need to use base64 encoding binary file so it can fit into xml payload, it theoretically works, but in the real world, if we pick a file from iphone photo library, it's usually around 1.2Mb, encoding will enlarge the file by 33%, not bad, but encoding the picture will take more than a minute, it's very bad user experience.

For better performance, we'd better use POST and GET the upload and download files, then we need to setup session, what we need to do:
# Assume user already got token, then user send token and file to a special script in Moodle, for example http://yourmoodle.com/files/ws_upload.php Moodle verify the token, if true, setup session, check permission, then allow uploading
# If users intend to download a moodle file served by pluginfile.php, first users request a special script with token, if token is valid, grant the session, then users will be able to access the files served by pluginfile.php, we need to http request in this case, if we can verify the token in pluginfile.php to reduce the http traffic, I'm not sure if it's acceptable.

--[[User:Dongsheng Cai|Dongsheng Cai]] 11:08, 20 April 2011 (WST)

Dropbox repository

2011-04-10T03:34:39Z

Dongsheng:

{{stub}}{{Moodle 2.0}}

A Dropbox repository can be enabled by an administrator in ''Site administration > Modules > Repositories > Manage repositories''.

==Sign up app keys at dropbox==

# Go to https://www.dropbox.com/developers/apps
# Create an app, you must change app status to Production
# Copy the app keys

==Configuration==
Once enabled by the administrator a Dropbox API Key and Secret will need to be added to the Dropbox settings in order for it to work. This will be ''the'' Dropbox available to all users throughout the site (and each will need the correct Dropbox login credentials to access it from their courses). To gather the Dropbox API Key and Secret click the "Dropbox Developers" link on the Dropbox repository settings page. On the next page you'll be prompted to login with your Dropbox username and password and to create a Dropbox app.

Once the App has been created at Dropbox.com you'll have the API Secret and Key available at the bottom of the App page. Entering those on the Dropbox settings page (and clicking Save) back in Moodle will finish the configuration. Dropbox is now available to the entire site.

To access it editing teachers need only "Add..." a new file while editing or creating a resource to see Dropbox as a new option.

==See also==

* [http://www.youtube.com/watch?v=V221JLCywWs Import files from Dropbox into Moodle 2.0 video]
* MDL-19168

[[Category:Repositories]]
[[de:Dropbox]]

Blocks 2.0.3 UI

2011-04-08T07:15:05Z

Dongsheng:

This page specs some refinements to the blocks config UI for Moodle 2.0.3. See MDL-26105 for details.

==Home context==

Indicate where the "home" context is for this block. The place it was created.

==Reduce page types==

Reduce the number of page type options using a callback so that all components can exactly specify what they support. If the component doesn't have a callback then fallback to the calculated list we have now.

==Sub-page types==

Instead of showing "This specific page (Page 13)" (the sub page id)
* Remove the "Page 13" completely
* Make the navbar show the page name: Sitename -> Site pages -> Tags -> My funky tag -> XXX Block -> Configuration

==User blocks==

Blocks created on user pages ie the My Moodle page or profile pages (including those that were copied from the default blocks the first time the user tries to customise the page) just need to show the page types menu to select between:

* Public user profile page (user-profile)
* Private "My Moodle" page (my-index)
* All pages (*)

Sub page type option should be hidden too, because it always being applied in user context.

This list will come from a callback function in /user/lib.php

==Module blocks==
Blocks should looking for page pattern from module callback which comes from /mod/$mod/lib.php

Blocks' page types should be limited to module context only, module will decide what types will be available. Some blocks are created at course level, and allowed to be displayed at the child contexts of course context, in this case, context selection should be kept. The original page type pattern should be kept as well.

Blocks' page contexts options should be module context only, there are no children contexts in modules.

==Course blocks==
Blocks added in course level can be displayed on module context, in this case , we don't need to display context options, page type pattern will override the context options.

Mobile Open Auth

2011-04-06T12:28:19Z

Dongsheng:

= Use case =
# the user launch the APP
# the user goes to settings
# the user add a site
# the user enter site url, website consumer key and website consumer secret
# the user is redirected to Moodle login page (an inside browser)
# the user login Moodle. Moodle displays a 'authentication requested by NAME_OF_THE_APP' button
# the user accepts and Moodle sends (displays ?) a Mobile ws token to the APP
# the APP tests the connection

= Technical specifciation =
A simple intro of how OAuth works, let's say moodle mobile app is a oauth client, moodle website as oauth server.
# oauth client needs consumer key and consumer secret to initiate an oauth session
# oauth client create signature by HMAC-SHA1 using consumer secret, consumer key, timestamp, nonce, callback, sending signature along with these parameters(except secret) to oauth server, then you got oauth token, oauth token secret
# oauth client open authorize_url (using oauth token as parameter), leave oauth token secret in client, click 'approve' button in authorize_url
# oauth server will direct you to your callback url, The callback request informs the client that user completed the authorization process
# Now use oauth token and oauth token secret to request access key (need to generate a new signature), store access key and access secret in oauth client, this is the final credentials you need for request protected resource, it need to be included in http header and the signature need to be updated as well.

Wiki 2.0.3 Files

2011-03-24T03:30:45Z

Dongsheng: New page: This page specs for cleaning up file handling in wiki 2. See MDL-26739 for details. ==File management page== Create a new tab in wiki main page, named "Files", the Files page will displa...

This page specs for cleaning up file handling in wiki 2. See MDL-26739 for details.

==File management page==
Create a new tab in wiki main page, named "Files", the Files page will display all files shared in current wiki instance. Users with manage files capability will see "Manage files" button under the files tree view, click the button will take users to moodle file manager.
[[Image:Wiki_Files_Tab.jpg]]

==Wiki editors==

Nwiki and creole wiki editors will have a new select to choose existing files from shared area.

[[Image:Wiki_Editor.jpg]]

==File handling==

Fil:Wiki Editor.jpg

2011-03-24T03:29:45Z

Dongsheng:

Fil:Wiki Files Tab.jpg

2011-03-24T03:20:32Z

Dongsheng:

Blocks 2.0.3 UI

2011-03-21T10:12:32Z

Dongsheng:

This page specs some refinements to the blocks config UI for Moodle 2.0.3. See MDL-26105 for details.

==Home context==

Indicate where the "home" context is for this block. The place it was created.

==Reduce page types==

Reduce the number of page type options using a callback so that all components can exactly specify what they support. If the component doesn't have a callback then fallback to the calculated list we have now.

==Upgrade block_instances->page_patterns==

All of the existing instances need to be upgraded to remove any settings that are no longer appearing in the UI. This will have to be implemented with an upgrade block in each module, added at the same time as the callback.

==Sub-page types==

Instead of showing "This specific page (Page 13)" (the sub page id)
* Remove the "Page 13" completely
* Make the navbar show the page name: Sitename -> Site pages -> Tags -> My funky tag -> XXX Block -> Configuration

==User blocks==

Blocks created on user pages ie the My Moodle page or profile pages (including those that were copied from the default blocks the first time the user tries to customise the page) just need to show the page types menu to select between:

* Public user profile page (user-profile)
* Private "My Moodle" page (my-index)
* All pages (*)

Sub page type option should be hidden too, because it always being applied in user context.

This list will come from a callback function in /user/lib.php

==Module blocks==
Blocks should looking for page pattern from module callback which comes from /mod/$mod/lib.php

Blocks' page types should be limited to module context only, module will decide what types will be available. Some blocks are created at course level, and allowed to be displayed at the child contexts of course context, in this case, context selection should be kept. The original page type pattern should be kept as well.

Blocks' page contexts options should be module context only, there are no children contexts in modules.

==Course blocks==
Blocks added in course level can be displayed on module context, in this case , we don't need to display context options, page type pattern will override the context options.

Blocks 2.0.3 UI

2011-03-14T10:15:24Z

Dongsheng: /* Module blocks */

This page specs some refinements to the blocks config UI for Moodle 2.0.3. See MDL-26105 for details.

==Home context==

Indicate where the "home" context is for this block. The place it was created.

==Reduce page types==

Reduce the number of page type options using a callback so that all components can exactly specify what they support. If the component doesn't have a callback then fallback to the calculated list we have now.

==Upgrade block_instances->page_patterns==

All of the existing instances need to be upgraded to remove any settings that are no longer appearing in the UI. This will have to be implemented with an upgrade block in each module, added at the same time as the callback.

==Sub-page types==

Instead of showing "This specific page (Page 13)" (the sub page id)
* Remove the "Page 13" completely
* Make the navbar show the page name: Sitename -> Site pages -> Tags -> My funky tag -> XXX Block -> Configuration

==User blocks==

Blocks created on user pages ie the My Moodle page or profile pages (including those that were copied from the default blocks the first time the user tries to customise the page) just need to show the page types menu to select between:

* Public user profile page (user-profile)
* Private "My Moodle" page (my-index)
* All pages (*)

This list will come from a callback function in /user/lib.php

==Module blocks==
Blocks should looking for page pattern from module callback which comes from /mod/$mod/lib.php

Blocks' page types should be limited to module context only, module will decide what types will be available. Some blocks are created at course level, and allowed to be displayed at the child contexts of course context, in this case, context selection should be kept. The original page type pattern should be kept as well.

Blocks' page contexts options should be module context only, there are no children contexts in modules.

Blocks 2.0.3 UI

2011-03-09T02:24:03Z

Dongsheng: /* Module blocks */

This page specs some refinements to the blocks config UI for Moodle 2.0.3. See MDL-26105 for details.

==Home context==

Indicate where the "home" context is for this block. The place it was created.

==Reduce page types==

Reduce the number of page type options using a callback so that all components can exactly specify what they support. If the component doesn't have a callback then fallback to the calculated list we have now.

==Upgrade block_instances->page_patterns==

All of the existing instances need to be upgraded to remove any settings that are no longer appearing in the UI. This will have to be implemented with an upgrade block in each module, added at the same time as the callback.

==Sub-page types==

Instead of showing "This specific page (Page 13)" (the sub page id)
* Remove the "Page 13" completely
* Make the navbar show the page name: Sitename -> Site pages -> Tags -> My funky tag -> XXX Block -> Configuration

==User blocks==

Blocks created on user pages ie the My Moodle page or profile pages (including those that were copied from the default blocks the first time the user tries to customise the page) just need to show the page types menu to select between:

* Public user profile page (user-profile)
* Private "My Moodle" page (my-index)
* All pages (*)

This list will come from a callback function in /user/lib.php

==Module blocks==
Blocks should looking for page pattern from module callback which comes from /mod/$mod/lib.php

Blocks' page types should be limited to module context only, module will decide what types will be available.

Blocks' page contexts options should be module context only, there are no children contexts in modules.

Blocks 2.0.3 UI

2011-03-09T02:21:28Z

Dongsheng:

This page specs some refinements to the blocks config UI for Moodle 2.0.3. See MDL-26105 for details.

==Home context==

Indicate where the "home" context is for this block. The place it was created.

==Reduce page types==

Reduce the number of page type options using a callback so that all components can exactly specify what they support. If the component doesn't have a callback then fallback to the calculated list we have now.

==Upgrade block_instances->page_patterns==

All of the existing instances need to be upgraded to remove any settings that are no longer appearing in the UI. This will have to be implemented with an upgrade block in each module, added at the same time as the callback.

==Sub-page types==

Instead of showing "This specific page (Page 13)" (the sub page id)
* Remove the "Page 13" completely
* Make the navbar show the page name: Sitename -> Site pages -> Tags -> My funky tag -> XXX Block -> Configuration

==User blocks==

Blocks created on user pages ie the My Moodle page or profile pages (including those that were copied from the default blocks the first time the user tries to customise the page) just need to show the page types menu to select between:

* Public user profile page (user-profile)
* Private "My Moodle" page (my-index)
* All pages (*)

This list will come from a callback function in /user/lib.php

==Module blocks==
Blocks should looking for page pattern from module callback which comes from /mod/$mod/lib.php

Blocks' page types should be limited to module context only, module will decide what types will be available.

WebDAV repository

2010-11-09T09:47:02Z

Dongsheng:

{{stub}}{{Moodle 2.0}}

A WebDAV repository can be enabled by an administrator in ''Site administration > Modules > Repositories > Manage repositories''.

==WebDAV configuration==

[[Image:Webdav config.png|thumb|WebDAV configuration]]After enabling the WebDAV repository, a repository instance can be created in ''Site administration > Modules > Repositories > WebDAV repository''.

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

WebDAV server: The server name

WebDAV path: The path to webdav directory

Authentication: We currently only support HTTP Basic Authentication

WebDAV server port: The webdav server port

WebDAV server user: HTTP Basic authentication username

WebDAV server password: HTTP Basic authentication password

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

==See also==

* MDL-22663

[[Category:Repositories]]

WebDAV repository

2010-11-09T06:40:00Z

Dongsheng:

{{stub}}{{Moodle 2.0}}

A WebDAV repository can be enabled by an administrator in ''Site administration > Modules > Repositories > Manage repositories''.

==WebDAV configuration==

[[Image:Webdav config.png|thumb|WebDAV configuration]]After enabling the WebDAV repository, a repository instance can be created in ''Site administration > Modules > Repositories > WebDAV repository''.

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

WebDAV server: The server name

WebDAV path: The path to webdav directory

Authentication: We currently only support HTTP Basic Authentication

WebDAV server port: The webdav server port

WebDAV server user: HTTP Basic authentication username

WebDAV server password: HTTP Basic authentication password

==See also==

* MDL-22663

[[Category:Repositories]]

Comments

2010-09-22T09:09:54Z

Dongsheng:

{{stub}}{{Moodle 2.0}}

==Basic Features==

===Comments anywhere===
Comments 2.0 implemented consistent interface for comments everywhere in Moodle 2.0, a new comment block is introduced, it can be added to all Moodle pages, so users can easily add comments on the page.

===Ajax interface===
The new comments interface uses Ajax to load/add comments without refresh current page, it is easy to use and consistent in Moodle.

=== Flexible capabilities===
Administrators are able to control if the user can see or use the comments block based on the context.

==See also==

* [[Development:Comments 2.0]]

Licences

2010-09-02T02:12:12Z

Dongsheng:

{{Moodle 2.0}}

* Unknown licence: people can use your course, modify your course, sell your course...
* [http://en.wikipedia.org/wiki/All_rights_reserved All rights reserved]
* [http://creativecommons.org/licenses/publicdomain/ Public domain]
* [http://creativecommons.org/licenses/by/3.0/ Creative Commons]
* [http://creativecommons.org/licenses/by-nd/3.0/ Creative Commons - NoDerivs]
* [http://creativecommons.org/licenses/by-nc-nd/3.0/ Creative Commons - No Commercial NoDerivs]
* [http://creativecommons.org/licenses/by-nd/3.0/ Creative Commons - No Commercial]
* [http://creativecommons.org/licenses/by-nc-sa/3.0/ Creative Commons - No Commercial ShareAlike]
* [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons - ShareAlike]

[[Category:Hub]]

Comments 2.0

2010-08-25T07:17:22Z

Dongsheng:

{{Moodle 2.0}}==Objectives==

The goals of comments 2.0:

* Manage comments centrally
* Use a consistent approach for all comments throughout Moodle
* Easily integrate comments 2.0 with existing modules
* Works no matter Javascript is enabled or not

==Overview==

The comments 2.0 provides APIs to:
# Add comments
# Manage comments
# Delete comments

And provides a fancy ajax interface to add/delete comments without loading a new page.

==Comments database table==

{| class="nicetable"
|-
! Field
! Type
! Default
! Info
|-
| id
| int(10)
| auto-incrementing
| The unique ID for this comment.
|-
| userid
| int(10)
|
| who wrote this comment
|-
| contextid
| int(10)
|
| The context id defined in context table - identifies the instance of plugin owning the comment.
|-
| itemid
| int(10)
|
| Some plugin specific item id (eg. forum post, blog entry or assignment submission)
|-
| commentarea
| int(10)
|
| for example, in user profile, you can comment user's description or interests, but they share the same itemid(==userid), we need comment_area to separate them
|-
| timecreated
| int(10)
|
|
|-
| timemodified
| int(10)
|
|
|-
| content
| text
|
| content of comment
|}

==Use Comments API==

===Add an option to format_text function===

Using this format_text function will add a comment icon automatically at the end of the text:

For example, using the following code in the forum module will add a comment icon to every post:

<code php>
$to = new stdclass;
$cmt->contextid = $modcontext->id;
$cmt->area = 'format_post';
$cmt->itemid = $post->id;
$options->comments = $cmt;
echo format_text($post->message, $post->messageformat, $options, $course->id)."<hr />";
</code>

===Use comment class===
To use Comments API elsewhere, using following code:
<code php>
$options->area = 'database_entry';
$options->context = $context;
$options->itemid = $record->id;
$options->showcount = true;
$comment = new comment($options);
$comment->output(false);
</code>
If you are using comments API in module context, you'd better add pluginname option, it will help comments API find callback functions faster:
<code php>
$options->area = 'database_entry';
$options->pluginname = 'data';
$options->context = $context;
$options->itemid = $record->id;
$options->component = 'mod_data';
$options->showcount = true;
$comment = new comment($options);
$comment->output(false);
</code>
==Comments API overview==

Generally speaking, only two functions you need to know to get comments 2.0 worked:
# Use comment::init to initialize comments 2.0
# Use $comment->output to display comments

The comment class has been implemented in comment/lib.php.
===class comment()===
====__construct($contextid, $comment_area, $itemid))====
Initialize class members

====init()====
It is a static function used to initialize comments, setting up languages, which must be called before html head printed

====output($return = false)====
Will print the html snippet for commenting interface, if set $return as true, it will return html string instead of printing out.

====print_comments($params = array())====
Used by non-javascript comment interface, will print a list of comments.

====add($content)====
Public instance funciton, add a comment to database, used in comment/comment_ajax.php

====count()====
Counting the number of comments

====delete($id)====
Delete a comment from database, used in comment/comment_ajax.php

====delete_comments====
Delete all comments in a specific contexts (like all comments belonging to a forum post)

==Javascript API==
Comments 2.0 implemented a YUI3 module M.core_comment to deal with the communication between browsers and moodle.
It can be found in comment/comment.js

Call M.core_comment.init will create an instance of CommentHelper class. You don't need to make any calls to this instance, it simply works out of box.

== Moodle modules callback ==
Comments API allows modules/blocks/blog to decide how comments display.

===Permission control===
Modules can implement a function named '''modname_comment_permissions''' to control post and view permission.

Blocks need to overwrite '''comment_permissions''' function of block_base.

Blog need to implement '''blog_comment_permissions''' function.

This function will return an array: array('post'=>true, 'view'=>true)

=== Check new added comment ===
The callback function allows you to change the comment content before inserting into database or reject this comment.

It takes two arguments, the comment object which contains comment details, and $params which contains context and course information.

Modules can implement a function named '''modname_comment_add'''.

Blocks need to overwrite '''comment_add''' function.

Blog need to implement '''blog_comment_add''' function.

This function should return a boolean value.

=== Filter/format comments ===
This callback allows modules check/format comments when user request to display comments.

It takes the same arguments as modname_comment_add

Modules can implement a function named '''modname_comment_display'''.

Blocks need to overwrite '''comment_display''' function.

Blog need to implement '''blog_comment_display''' function.

It will return the comment object.

=== Define a comment template ===
Modules can implement a function named '''modname_comment_template''', which allow modules define a comment template.
The template must have 4 embedding variables, ___id___, ___content___, ___time___, ___name___, they will be replaced with html id, comments content, comment time and commenter name

==See also==
* MDL-19118 - Comments 2.0 issue

Broken/File storage conversion Quiz and Questions

2010-07-14T09:36:06Z

Dongsheng: New page: Hi, Tim FYI, the editor moodle form element has three fields: text, format and itemid, so we don't need to add extra format and itemid fields to moodle form. Currently , question bank uses...

Hi, Tim
FYI, the editor moodle form element has three fields: text, format and itemid, so we don't need to add extra format and itemid fields to moodle form. Currently , question bank uses htmleditor element which doesn't have format and itemid, I am working on to switch it to the new editor element.

File storage conversion Quiz and Questions

2010-07-14T09:04:00Z

Dongsheng: changes against latest file api update

This page are some notes about what has to be done for MDL-16094.

I would like to review code changes before they are committed for all of this, but I can't see myself having time to do much work on this, only to help someone else do it.

==Assumptions==

I believe it is the case that each HTML editor on a form has to use a separate HTML editor (otherwise copying files to and from draft areas does not work). However, for question types, I don't think that leads to the best usability.

Similarly, each HTML editor has to have a corresponding ...format field (like questiontext, questiontextformat) even though it is silly (from a usability point of view) for different parts of a question to use different formats.

==Serving files==

Files belonging to the quiz are served using the quiz_pluginfile() function and other callbacks in mod/quiz/lib.php, as for other modules. There is nothing special here.

The issue is with files belonging to questions. Doing proper access control before serving these files involves coordinating both the question type, and the activity (e.g. the quiz) that is using the questions.

Question components will be given names like question, or qtype_yyy, where yyy is the name of the particular question type, for example multichoice. And question file areas are requires as well, such as intro, feedback etc.

All questions belong to a particular context, via the link mdl_question.category -> mdl_question_categories.id, mdl_question_categories.contextid -> mdl_context.id links. This is the context id that should be used for files belonging to that question.

Therefore, the URL for serving a file belonging to a question will look like one of these examples:

$CFG->wwwroot/pluginfile.php/$questioncontextid/question/generalfeeback/$attemptid/$questionid/$itemid/path/to/file.ext
$CFG->wwwroot/pluginfile.php/$questioncontextid/qtype_match/stem/$attemptid/$questionid/$itemid/path/to/file.ext

The $attemptid here is the id from the row of the mdl_question_attempts table for the quiz (or whatever) attempt that is using the question. In the question code, where we are outputting a question, the $attemptid and $questionid are normally available from the $state variable as $state->attempt and $state->question. Currently, question/preview.php does not store things in the database. It just uses the session, and a fake $attemptid of 0. That is not a problem (for us here. It is a problem in other ways.)

Therefore in pluginfile.php, we need code for any system, course category, course or module context, sends requests for files in a question_... or qtype_... file area to a question_pluginfile() function in lib/questionlib.php.

Next, we need to get some information from the thing (e.g. quiz) that the attempt belongs to. To identify the 'thing':
* If $attemptid is 0, then thing is core_question_preview
* Otherwise, load the row from mdl_question_attempts, and looks at the modulename field. The will contain something like 'quiz' which is the thing.

Next question_pluginfile calls a callback:
list($question, $state, $options) =
thing_check_file_access($attemptid, $questionid, $context);
This does some basic access checks (For quiz, it will to something similar to the top of attempt.php and review.php, for core preview it just does some capability checks like at the top of question/preview.php.) If the user is not allowed to see the file, based on the quick check, a lot of nulls are returned. If access is allowed, $question, $state, $options are returned. These are the things that would be passed to print_question.

Finally, we call
$qtype->check_file_access($question, $state, $options, $filearea, $itemid);
which returns true if the file can be served, or false if not. This will contain logic similar to that in ->print_question_formulation_and_controls to determine whether the file should be displayed. It should also check that $itemid for this file area belongs to this question.

==File areas for the quiz==

I have written what follows with reference to database columns, with secondary mention of the editing forms where the value is edited. That determines what itemid should be used with each file area (the id of the row from that table) but for clarity, for each file area I think we need, I have added a notation that looks like {contextid, area_name, itemid} to make it clear what the file areas are.

[[Development:Quiz database structure]]

* We need a file area for quiz.intro. {$quizcontextid, quiz_intro, ???}

* We need a file area for quiz_feedback.feedbacktext. (The overall feedback on the quiz settings form.) If it is possible to do easily, we should replace the overall feedback boxes with HTML editors (the boxes currently accept HTML input into text fields, which is functionally complete, but sucky). {$quizcontextid, quiz_feedback, quiz_feedback.id}

* We need to add a feedbacktextformat column, if it has not already been done.

* Ideally, access to overall feedback files should be controlled by the same logic as whether the feedback itself is displayed. However, I think it would be acceptable to release Moodle 2.0 without this. Just leave an open tracker issue assigned to me, and I can implement that check later.

No other quiz_... tables have files associated with any columns.

==File areas for questions==

[[Development:Question database structure]]

There are no fields in the 'question engine' tables that have files. Except:

* There should be a question_sessions.manualcommentformat column. (But manual comment should not support attached files.)

All the issues are in the 'question bank' part, which means the core question bank, and the all the question type plugins.

===Core question bank===

There is a context associated with each question, as explained in the [[#Serving_files|Serving files]] section.

* I think that question_categories.info (which is HTML) should not have files. However, we need a question_categories.infoformat field.

* We need file areas for question.questiontext and question.generalfeedback. We also need to add the missing question.generalfeedbackformat field. {$questioncontextid, question_text, question.id} {$questioncontextid, question_generalfeedback, question.id}

* We need file areas, and ...format columns for question_answers.answer and question_answers.feedback. (Depending on the question type, question_answers.answer may be HTML, or it may not, but where it is not, we will force the ...format value to something appropriate. Anyway, as an example, answers are HTML for multichoice and truefalse, but not for numerical or shortanswer.) {$questioncontextid, question_answer, question_answer.id} {$questioncontextid, question_answer_feedback, question_answer.id}

* We must get rid of the question.image column. We need an upgrade to:
*# Do a database upgrade that appends an img tag to the questiontext, if the img column is not empty;
*# and copy the file into the right file area;
*# then drop the question.image column;
*# remove that field from all editing forms;
*# remove the places where the image is displayed.

Note that all the above changes require changes to the question editing form for all question types, but hopefully that can mostly be done in the form base class.

* Question import needs to use the file-picker.

* Question export should be changed to put the files in an appropriate file area. I am not sure what the best file area is right now, but probably somewhere in the user context. MDL-15573

===Question types===

====Question types where nothing needs to be done====

These only use the core question tables, or do not need files associated with their own tables.

* Description
* Essay
* Missing type
* '''Numerical'''
''The new 2,0 number and unit grading use a new table question_numerical_options where the instructions field is HTML which could include images. This table is also used by calculated and calculated simple.--Pierre Pichet 08:11, 23 May 2010 (UTC)''
* Random
* Random short-answer matching
* Short answer
* True-false

====Match====

* question_match_sub.questiontext needs a ...format column and a file area. (answertext does not. It is displayed in a select menu.) {$questioncontextid, qtype_match_stem, question_match_sub.id}

====Multiple choice====

* correctfeedback, partiallycorrectfeedback and incorrectfeedback all need ...format columns and a file area.
{$questioncontextid, qtype_multichoice_correctfeedback, question_multichoice.id} {$questioncontextid, qtype_multichoice_partiallycorrectfeedback, question_multichoice.id} {$questioncontextid, qtype_multichoice_incorrectfeedback, question_multichoice.id}

* The choice entry boxes on the editing form should be changed to HTML editors.

====Question types I am not really sure about====

* Calculated* - I don't really know what Pierre is doing here. I need to get my head round it.

So here is the status of calculated in 2.0.

The calculatedsimple is just a regular calculated that can be edited in a one page because it is not using the shared category datasets. In both on them there is no new field with image to store other than question text and answer feedback.

The answer field is just math formula i.e. plain text.

The multichoice calculated is a multichoice where calculated math formula can be inserted {=...} so the requirements are the same as regular multichoice.

Regular calculated and multichoice calculated used the new table question_calculated_options although regular calculated only used the synchronize field, multichoice calculated using the other fields.
I prefer to use only one new table and the fields for multichoice calculated are a copy of most of the multichoice ones.

This is a new table in 2.0 so no file conversion.

[[User:Pierre Pichet|Pierre Pichet]] 08:01, 23 May 2010 (UTC)

* Multi-answer - probably does not need any other file areas, but the code may need fixing a bit.

So here is the status of Multi-answer in 2.0.

Multi-answer code is the same has in 1.9, the improvements has been on the data validation in the edit_form with additional warnings when the user modify the number or question type in the question text peculiarly when the question has attempts stored.

I am working on the lang strings.

[[User:Pierre Pichet|Pierre Pichet]] 08:01, 23 May 2010 (UTC)

==For the future==

As in, Moodle 2.1 or later.

* Support files in student responses and manual comments.

==See also==

* MDL-16094
* Feel free to discuss this with Tim Hunt.

Web services:Files

2010-07-09T07:50:40Z

Dongsheng:

These APIs will be used to browse Moodle files by Moodle Web Services.

===class moodle_file_external()===

This class implements the interface to moodle files, for browsing, downloading and uploading files. It is defined in files/externals.php.

We cannot return the whole files tree by web service API, because to make sure the web services working in every language and platform, we need to define a fixed data structure of return value, but the files tree can change all the time. See more information about web services at: [[Development:External_services_description]].

The class contains following methods:

====get_files====
This function is used to browse files.

It takes 5 parameters, all of them are optional, if you provide no parameters, it will return the top level content of moodle repository.

* contextid
* component
* filearea
* itemid
* filename
* filepath

It will return an array, can be described as PHP array:
<pre>
$files = array(
'path' => array(array('name'=>'root', 'path=>'/'), array('name'=>'subdir', 'path=>'/sub/')),
'files' => array(
array('filename'=>'readme', 'filepath'=>'/', 'filearea'=>'forum', 'itemid'=>110, 'contextid'=>1, 'isdir'=>true),
array('filename'=>'changes', 'filepath'=>'/', 'filearea'=>'forum', 'itemid'=>112, 'contextid'=>1, 'isdir'=>false),
)
);
</pre>

The service name is "moodle_file_get_files", defined in lib/db/services.php.

====upload====
This function is used to upload a file to user private area.

It takes 7 parameters, all of them are mandatory:

* contextid
* component
* filearea
* itemid
* filepath
* filename
* filecontent

It will return a boolean value, true/false.

The service name is "moodle_file_upload", defined in lib/db/services.php

Sample code (using Zend Framework):
<code php>
$url = MOODLE_WSROOT. '?wstoken=xxxxxxxxxxxxxxxxxxxxxx';
$zend = new Zend_XmlRpc_Client($url);
$srv = $zend->getProxy();
$files = $srv->moodle_file_get_files($contextid, $component, $filearea, $itemid, $filepath, $filename);
$file = $srv->moodle_file_upload($contextid, 'user', 'private', 0, '/', 'info.txt', base64_encode('this is file content'));
</code>

Repository plugins

2010-07-05T07:39:33Z

Dongsheng:

A guide for developers on how to create a repository plugin.

== Introduction ==
===Prerequisites===
Before starting coding, it is necessary to know how to use repository administration pages and how to use the file picker.

There is a template attached to MDL-16543 which might be useful to help get you started.

===First steps===
# Create a folder for your plugin in ''moodle/repository/'' e.g. ''moodle/repository/myplugin''
# Create the following files and add them to the plugin folder:
#* ''lib.php''
#* ''pix/icon.png'' (the icon displayed in the file picker)
#* "version.php"
# Create the language file ''repository_myplugin.php'' and add it to the plugin folder, keeping the following folder structure:
#*''moodle/repository/myplugin/lang/en_utf8/repository_myplugin.php'' or ''moodle/lang/en_utf8/repository_myplugin.php''
# Create access.php and upgrade scripts

===Overview===

The 3 different parts to write
# Administration - You can customise the way administrators and users can configure their repositories.
# File picker integration - The core of your plugin, it will manage communication between Moodle and the repository service, and also the file picker display.
# I18n - Internationalization should be done at the same time as you're writing the other parts.

==Administration APIs==

As an example, let's create a Flickr plugin for accessing a public flickr account. The plugin will be called "Flickr Public".

Firstly the skeleton:

<code php>
<?php
/**
* repository_flickr_public class
* Moodle user can access public flickr account
*
* @license http://www.gnu.org/copyleft/gpl.html GNU Public License
*/
class repository_flickr_public extends repository {
}
?>
</code>

Then consider the question "What does my plugin do?"

In the Moodle file picker, we want to display some flickr public repositories directly linked to a flickr public account. For example ''My Public Flickr Pictures'', and also ''My Friend's Flickr Pictures''. When the user clicks on one of these repositories, the public pictures are displayed in the file picker.

In order to access to a flickr public account, the plugin needs to know the email address of the Flickr public account owner. So the administrator will need to set an email address for every repository. Let's add an "email address" setting to every repository.

<code php>
//We tell the API that the repositories have specific settings: "email address"
public static function get_instance_option_names() {
return array('email_address');
}

//We add an "email address" text box to the create/edit repository instance Moodle form
public function instance_config_form(&$mform) {
$mform->addElement('text', 'email_address', get_string('emailaddress', 'repository_flickr_public'));
$mform->addRule('email_address', get_string('required'), 'required', null, 'client');
}
</code>

So at this moment all our Flickr Public Repositories will have a specific email address. However this is not enough. In order to communicate with Flickr, Moodle needs to know a Flickr API key (http://www.flickr.com/services/api/). This API key is the same for any repository. We could add it with the email address setting but the administrator would have to enter the same API key for every repository. Hopefully the administrator can add settings to the plugin level, impacting all repositories. The code is similar the repository instance settings:
<code php>
//We tell the API that the repositories have general settings: "api_key"
public static function get_type_option_names() {
return array('api_key');
}

//We add an "api key" text box to the create/edit repository plugin Moodle form (also called a Repository type Moodle form)
public function type_config_form(&$mform) {
//the following line is needed in order to retrieve the API key value from the database when Moodle displays the edit form
$api_key = get_config('flickr_public', 'api_key');
$mform->addElement('text', 'api_key', get_string('apikey', 'repository_flickr_public'),
array('value'=>$api_key,'size' => '40'));
$mform->addRule('api_key', get_string('required'), 'required', null, 'client');
}
</code>

Have we finished yet?

Yes! We have created everything necessary for the administration pages. But let's go further. It would be good if the user can enter any "Flickr public account email address" in the file picker. In fact we want to display in the file picker a Flickr Public repository that the Moodle administrator can never delete. Let's add:

<code php>
//this function is only called one time, when the Moodle administrator add the Flickr Public Plugin into the Moodle site.
public static function plugin_init() {
//here we create a default repository instance. The last parameter is 1 in order to set the instance as readonly.
repository_static_function('flickr_public','create', 'flickr_public', 0, get_system_context(),
array('name' => 'default instance','email_address' => null),1);
}
</code>

That's all - the administration part of our Flickr Public plugin is done. For your information, Box.net, Flickr, and Flickr Public all have similar administration APIs.

===Functions===
All of the following functions are optional. If they're not implemented, your plugin will not have manual settings and will have only one instance displayed in the File Picker (The repository API creates this unique instance when the administrator add the plugin).

==== get_instance_option_names====
''This function must be declared static'' 
Return an array of strings. These strings are setting names. These settings are specific to an instance.
If the function returns an empty array, the API will consider that the plugin displays only one repository in the file picker.
Parent function returns an empty array.

====instance_config_form(&$mform)====
This is for modifying the Moodle form displaying the settings specific to an instance.

For example, to add a required text box called email_address:
<code php>
$mform->addElement('text', 'email_address', get_string('emailaddress', 'repository_flickr_public'));
$mform->addRule('email_address', $strrequired, 'required', null, 'client');
</code>

''Note: ''mform'' has by default a name text box (cannot be removed).''

Parent function does nothing.

====get_type_option_names====
''This function must be declared static'' 
Return an array of string. These strings are setting names. These settings are shared by all instances.
Parent function return an empty array.

====type_config_form(&$mform)====
This is for modifying the Moodle form displaying the plugin settings.
Similar to ''instance_config_form(&$mform)''

====plugin_init()====
''This function must be declared static'' 
This function is called when the administrator adds the plugin. So unless the administrator deletes the plugin and re-adds it, it should be called only once.
Parent function does nothing.

==File picker APIs==
=== Quick Start ===
'''To be completed''' 
First of all, the File Picker using intensively Ajax you will need a easy way to debug. Install FirePHP (MDL-16371) and make it works. It will save you a lot of time. (You might give the [http://moodle.org/mod/forum/discuss.php?d=119961 FirePHP plugin for Moodle] a try, it's still work in progress, though.)

Your first question when you write your plugin specification is 'Does the user need to log-in'? 
.....

For most of plugins, you need to establish a connection with the remote repository. This connection can be done into the get_listing(), constructor() function... 
.....

You wanna display a list of files once the user is logged 
.... get_listing() .....

You wanna retrieve the file that the user selected 
....

Optional question that you should ask yourself is 'Does the user can execute a search' 
.... search() ....

===Functions you *MUST* override===
====__construct====
You may initialize your plugin here, such as:
# Get options from database
# Get user name and password from HTTP POST

====get_listing($path="", $page="")====
This function will return a list of files, the list must be a array like this:
<code php>
$list = array(
//this will be used to build navigation bar
'path'=>array(array('name'=>'root','path'=>'/'), array('name'=>'subfolder', 'path'=>'/subfolder')),
'manage'=>'http://webmgr.moodle.com',
'list'=> array(
array('title'=>'filename1', 'date'=>'01/01/2009', 'size'=>'10MB', 'source'=>'http://www.moodle.com/dl.rar'),
array('title'=>'folder', 'date'=>'01/01/2009', 'size'=>'0', 'children'=>array())
)
);
</code>
'''The full specification of list element:'''
<code php>
array(
// Used to build navegation bar, so you need to include all parents folders
// array(array('name'=>'root','path'=>'/'), array('name'=>'subfolder', 'path'=>'/subfolder'))
'path' => (array) this will be used to build navigation bar
// dynload tells file picker to fetch list dynamically, when user click
// the folder, it will send a ajax request to server side.
// if you are using pagination, 'page' and 'pages' parameters should be used
// and note, you'd better don't use pagination and page at the same time
'page' => (int) which page is this list
'pages' => (pages) how many pages
'dynload' => (bool) use dynamic loading,
// will display a link in file picker
'manage' => (string) url of the file manager,
// set to true, the login link will be removed from file picker
'nologin' => (bool) requires login,
// set to true, the search link will be removed from file picker
'nosearch' => (bool) no search link,
// set this option will display a upload form in file picker
// only used in upload plugin currently
'upload' => array( // upload manager
'label' => (string) label of the form element,
'id' => (string) id of the form element
),
// file picker will build a file tree according this
// list
'list' => array(
array( // file
'title' => (string) file name,
'shorttitle' => (string) optional, if you prefer to display a short title
'date' => (string) file last modification time, usually userdate(...),
'size' => (int) file size,
'thumbnail' => (string) url to thumbnail for the file,
'thumbnail_width' => (int) the width of the thumbnail image,
'source' => plugin-dependent unique path to the file (id, url, path, etc.),
'url'=> the accessible url of file
),
array( // folder - same as file, but no 'source'.
'title' => (string) folder name,
'shorttitle' => (string) optional, if you prefer to display a short title
'path' => (string) path to this folder
'date' => (string) folder last modification time, usually userdate(...),
'size' => 0,
'thumbnail' => (string) url to thumbnail for the folder,
'children' => array( // an empty folder needs to have 'children' defined, but empty.
// content (files and folders)
)
),
)
)
</code>
Dynamically loading
Some repositories contain many files which cannot load in one time, in this case, we need dynamically loading to fetch them step by step, files in subfolder won't be listed until user click the folder in file picker treeview.

As a plug-in developer, if you set dynload flag as '''true''', you should return files and folders (set children as a null array) in current path instead of building the whole file tree.

Example of dynamically loading
See [http://cvs.moodle.org/moodle/repository/alfresco/lib.php?view=log Alfresco] plug-in

===Functions you can override===
====print_login====
This function will help to print a login form, for the Ajax file picker, this function will return a
PHP array to define this form.
<code php>
public function print_login(){
if ($this->options['ajax']) {
$user_field->label = get_string('username', 'repository_boxnet').': ';
$user_field->id = 'box_username';
$user_field->type = 'text';
$user_field->name = 'boxusername';
$user_field->value = $ret->username;

$passwd_field->label = get_string('password', 'repository_boxnet').': ';
$passwd_field->id = 'box_password';
$passwd_field->type = 'password';
$passwd_field->name = 'boxpassword';

$ret = array();
$ret['login'] = array($user_field, $passwd_field);
// if you are going to rename submit button label, use this option
//$ret['login_btn_label'] = get_string('submit_btn_label');
// if you are going to display a search form instead of login form
// set this option to true
//$ret['login_search_form'] = true;
return $ret;
}
}
</code>
This will help to generate a form by file picker which contains user name and password input elements.

If your plugin don't require logging in, you don't need to override it, it will call get_listing to list files automatically by default.
====check_login====
This function will return a boolean value to tell Moodle whether the user has logged in.
By default, this function will return true.
====logout====
When a user clicks the logout button in file picker, this function will be called. You may clean up the session or disconnect the connection with remote server here.
====print_search====
When a user clicks the search button on file picker, this function will be called to return a search form. By default, it will create a form with single search bar - you can override it to create a advanced search form.
====search====
This function will do the searching job. You can obtain the POST parameters from the from the form you created in print_search function
This function will return a file list exactly like the one from get_listing.
====get_file====
When a user clicks the "Get" button to transfer the file, this function will be called. Basically, it will download a file to Moodle - you can override it to modify the file then move it to a better location.
====get_name====
This function will return the name of the repository instance.

== I18n - Internationalization ==
These following strings are required in ''moodle/repository/myplugin/lang/en_utf8/repository_myplugin.php'' or ''moodle/lang/en_utf8/repository_myplugin.php'':

<code php>
$string['configplugin'] = 'Flickr Public configuration';
$string['repositorydesc'] = 'A Flickr public repository';
$string['repositoryname'] = 'Flickr Public';
</code>

== Standard repository plugins ==
This is the functional specification list of the officially supported repository plugins.
For each plugins, the two mains part we are interested in are:
* How do I administrate the plugin? See [[Development:Repository_Administration_Specification| Repository Administration Specification - UC001-3]]
* How do I set up an account for this repository? See [[Development:Repository_Interface_for_Moodle/Course/User| Repository Interface for Moodle/Course/User]]

=== Functional specifications ===
*[[Development:Box.net Repository Plugin|Box.net Repository Plugin]]
*[[Development:Flickr Repository Plugin|Flickr Repository Plugin]]
*[[Development:Moodle Repository Plugin|Remote Moodle Repository Plugin]]

==See also==

*[[Development:Repository API| Repository API]]
*[[Development:Repository_Interface_for_Moodle/Course/User| Repository Interface for Moodle/Course/User]]
*[[QA:Use Case Number Attribution| Use Case Number Attribution]]
* MDL-16543 - A list of officially supported repository plugins
* MDL-16543 - Template plugin for developers
[[Category:Repositories]]

Using the File API in Moodle forms

2010-05-28T03:21:57Z

Dongsheng:

{{Moodle 2.0}}

This document shows you exactly how to use Moodle forms to get files from users in a standard and secure way.

==Overview==

In Moodle 2.0 all files are stored in a central database accessible via the [[Development:File API|File API]], and every file is associated with a "file area" in Moodle, such as a particular module.

A common use case is to provide a form (using Moodle's [[Development:lib/formslib.php|Forms API]]) which allows users to upload or import files as attachments or media embedded into HTML.

Normally this works like this:
# User starts creation or re-edits an existing item in Moodle (eg forum post, resource, glossary entry etc)
# User presses some sort of button to browse for new files to attach or embed
# User sees our "Choose file..." dialog, which contains one or more repository instances.
# User chooses a file, the [[Development:Repository API|Repository API]] takes care of copying the file into a "draft file area" within Moodle
# File appears in the text or as an attachment in the form.
# When the user hits save, the [[Development:File API|File API]] is invoked to move the file from the draft file area into a permanent file area associated with that data

This document shows you exactly how to use Moodle forms to interact with users in a standard and secure way.

If you just want to write code to manipulate Moodle files internally (without user input) then see [[Development:Using_the_File_API]].

==Form elements==

In Moodle 2.0 there are three file-related form elements for interacting with users:

# filemanager - the way to attach one or more files as a set
# editor - the way to specify a textarea with a HTML editor, and all the handling of images and movies within that HTML
# filepicker - a way to specify one file for the case when you want to process the file and throw it away

In Moodle 1.9 there were two other types which are now '''deprecated''' (they work, but please do not use these anymore)
# file - used to just allow a normal file upload from the desktop only.
# htmleditor - this old method of embedding a HTML editor in a textarea is not able to support repositories etc.

===filepicker===

File picker (''filepicker'') is a direct replacement of the older ''file'' formslib element.

It is intended for situations when you want the user to upload '''one''' file so you can process it and delete it, such as when you are importing data from a CSV file.

==== Using the filepicker element ====

<code php>
$mform->addElement('filepicker', 'userfile', get_string('file'), null, array('maxbytes' => $maxbytes, 'accepted_types' => '*'));
</code>

==== Obtain the chosen file ====

The API for getting file contents is exactly the same as for ''file'' element.

<code php>
$content = $mform->get_file_content('userfile');
</code>

=== filemanager ===

The File Manager element improves on file picker by allowing you to manage more than one file. It is expected that the files will be stored permanently for future use (such as forum and glossary attachments).

==== Add file manager element ====

Example:
<code php>
$mform->addElement('filemanager', 'attachments', get_string('attachment', 'moodle'), null,
array('subdirs' => 0, 'maxbytes' => $maxbytes, 'maxfiles' => 50, 'accepted_types' => array('document') ));
</code>

Here are the fields for filemanager:

;'filemanager':This is a filemanager element :)
;elementname:The unique name of the element in the form
;elementlabel:The label string that users see
;attributes:(leave it as null)
;options: an array of further options for the filepicker (see below)

The options array can contain:

;subdirs:(Default 0) Are subdirectories allowed? (true or false)
;maxbytes:(Default 0) Restricts the total size of all the files.
;maxfiles:(Default -1) Restricts the total number of files.
;accepted_types:(Default *) You can specify what file types are accepted by filemanager. All current file types are listed in this file: [http://cvs.moodle.org/moodle/lib/file/file_types.mm moodle/lib/file/file_types.mm]. This is a [http://freemind.sourceforge.net/wiki/index.php/Main_Page freemind] file: if it is edited the changes will be immediately reflected in Moodle. Example usage: '''array('audio', 'video', 'documents')''', you can include file extensions as well, for example: '''array('*.txt', '*.jpg', 'audio')'''.

==== Load existing files into draft area ====

<code php>
if (empty($entry->id)) {
$entry = new object();
$entry->id = null;
}

$draftitemid = file_get_submitted_draft_itemid('attachments');
file_prepare_draft_area($draftitemid, $context->id, 'glossary_attachment', $entry->id, array('subdirs' => 0, 'maxbytes' => $maxbytes, 'maxfiles' => 50));
$entry->attachments = $draftitemid;

$mform->set_data($entry);

</code>

==== Store updated set of files ====

<code php>
if ($data = $mform->get_data()) {
// ... store or update $entry
file_save_draft_area_files($data->attachments, $context->id, 'glossary_attachment', $entry->id, array('subdirs' => 0, 'maxbytes' => $maxbytes, 'maxfiles' => 50));
}
</code>

===editor===
There are two way for using of editor element in code, the first one is easier but expects some standardized fields. The second method is more low level.

====Simple use====
# name database fields: ''textfield'', ''textfieldformat'' (and ''textfieldtrust'' if required)
# create options array <code php>$textfieldoptions = array('trusttext'=>true, 'subdirs'=>true, 'maxfiles'=>$maxfiles, 'maxbytes'=>$maxbytes);</code>
# add editor ''textfield_editor'' to moodle form, pass options through custom data in form constructor, set $data->id to null if data not exist yet <code php>$mform->addElement('editor', 'textfield_editor', get_string('fieldname', 'somemodule'), null, $textfieldoptions);</code>
# prepare data <code php>$data = file_prepare_standard_editor($data, 'textfield', $textfieldoptions, $context, 'somemodule_somearea', $data->id);</code>
# get submitted data and after inserting/updating of data <code php>$data = file_postupdate_standard_editor($data, 'textfield', $textfieldoptions, $context, 'somemodule_somearea', $data->id);</code>

Real world examples are in mod/glossary/edit.php and mod/glossary/comment.php

====Low level use====

When using editor element you need to preprocess and postprocess the data:
# detect if form was already submitted (usually means draft is area already exists) - ''file_get_submitted_draft_itemid()''
# prepare draft file area, temporary storage of all files attached to the text - ''file_prepare_draft_area()''
# convert encoded relative links to absolute links - ''file_prepare_draft_area()''
# create form and set current data
# after submission the changed files must be merged back into original area - ''file_save_draft_area_files()''
# absolute links have to be replaced by relative links - ''file_save_draft_area_files()''

=====Replace old htmleditor with editor=====

The file picker has been integrated with with TinyMCE to make the editor element. This new element should support all types on editors and should be able to switch them on-the-fly. Instances of the old htmleditor element in your forms should be replaced by the new editor element, this may need adding of new format and trusttext columns. For example:
<code php>
$mform->addElement('editor', 'entry', get_string('definition', 'glossary'), null,
array('maxfiles' => EDITOR_UNLIMITED_FILES, 'filearea' => 'glossary_entry'));
</code>
The editor element can take following options: maxfiles, maxbytes, filearea, subdirs and changeformat. Please note that the embedded files is optional feature and is not expected be used everywhere.

'''Note''': the editor element now includes text format option. You should no longer use the separate format element type.

=====Prepare current data - text and files=====

<code php>
if (empty($entry->id)) {
$entry = new object();
$entry->id = null;
$entry->definition = '';
$entry->format = FORMAT_HTML;
}

$draftid_editor = file_get_submitted_draft_itemid('entry');
$currenttext = file_prepare_draft_area($draftid_editor, $context->id, 'glossary_entry', $entry->id, array('subdirs'=>true), $entry->definition);
$entry->entry = array('text'=>$currenttext, 'format'=>$entry->format, 'itemid'=>$draftid_editor);

$mform->set_data($entry);
</code>

If there are multiple files, they will share the same itemid.

=====Obtain text, format and save draft files=====

To retrieve editor content, you need to use following code:

<code php>
if ($fromform = $mform->get_data()) {
// content of editor
$messagetext = $fromform->entry['text'];
// format of content
$messageformat = $fromform->entry['format'];
}
</code>

When a user selects a file using the file picker, the file is initially stored in a draft file area, and a URL is inserted into the HTML in the editor that lets the person editing the content (but no one else) see the file.

When the user submits the form, we then need to save the draft files to the correct place in permanent storage. (Just like you have to call $DB->update_record('tablename', $data); to have the other parts of the form submission stored correctly.)

The save_files_from_draft_area function and replace absolute links with internal relative links do:
<code php>
$messagetext = file_save_draft_area_files($draftid_editor, $context->id, 'glossary_entry', $entry->id, array('subdirs'=>true), $messagetext);
</code>
; $context->id, 'proper_file_area' and $entry->id : correspond to the contextid, filearea and itemid columns in the [[Development:File_API#Table:_files|files table]].
; $messagetext : this is the message text. As the files are saved to the real file area, the URLs in this content are rewritten.

All URLs in content that point to files managed to the File API are converted to a form that starts '@@PLUGINFILE@@/' before the content is stored in the database. That is what we mean by rewriting.

== File serving==

=== Convert internal relative links to absolute links ===

Before text content is displayed to the user, any URLs in the '@@PLUGINFILE@@/' form in the content need to be rewritten to the real URL where the user can access the files.
<code php>
$messagetext = file_rewrite_pluginfile_urls($messagetext, 'pluginfile.php',
"$context->id/proper_file_area/$itemid/");
</code>
; $messagetext : is the content containing the @@PLUGINFILE@@ URLs from the database.
; 'pluginfile.php' : there are a number of different scripts that can serve files with different permissions checks. You need to specify which one to use.
; "$context->id/proper_file_area/$itemid/" : uniquely identifies the file area, as before.

=== Implement file serving access control ===

Attachments and embedded images should have the same access control like the text itself, in majority of cases these files are served using pluginfile.php. Access control is defined in ''module/lib.php'' file in function ''module_pluginfile()''.

== File browsing support ==
Only owner of each file area is allowed to use low level File API function to access files, other parts of Moodle should use file browsing API.

Activities may specify browsing support in own module/lib.php file by implementing functions module_get_file_areas() and module_get_file_info().

== Upgrading your code ==
Here I will attempt to describe some simple steps you can take to upgrade your file-handling form elements from pre-2.0 code to 2.0. We will use the example of glossary, since it has been used above.

=== Preparing your options ===
Unless you are happy with the defaults, you will need to define an array of options for each file-handling form element. You could define it at different places, but it's best to put it in one place and make the array(s) available to other files if they need it. In the majority of cases, this will be in a file like edit.php

Previous code in mod/glossary/edit.php:
<code php>
$mform =& new mod_glossary_entry_form(null, compact('cm', 'glossary', 'hook', 'mode', 'e', 'context'));
</code>
New code:
<code php>
$maxbytes = $course->maxbytes; // Could also use $CFG->maxbytes if you are not coding within a course context
$definitionoptions = array('subdirs'=>false, 'maxfiles'=>99, 'maxbytes'=>$maxbytes, 'trusttext'=>true, 'context'=>$context);
$attachmentoptions = array('subdirs'=>false, 'maxfiles'=>99, 'maxbytes'=>$maxbytes);
$mform = new mod_glossary_entry_form(null, array(
'current'=>$entry,
'cm'=>$cm,
'glossary'=>$glossary,
'definitionoptions'=>$definitionoptions,
'attachmentoptions'=>$attachmentoptions));
</code>
Note that the data being passed to the form constructor have changed also, but this is not part of the file API changes, I just include them to avoid confusion.

These options are for the htmleditor (definition field) and the filemanager (attachment field). They are used by a file called edit_form.php.

=== Element preparation ===
Before we look at this, however, we need to "prepare" the elements so that they can correctly display existing embedded images and attached files when you are editing a record instead of just creating one. So, let's take the code we've got so far in edit.php and add to it:

Currently upgraded code in edit.php:
<code php>
$mform = new mod_glossary_entry_form(null, array(
'current'=>$entry,
'cm'=>$cm,
'glossary'=>$glossary,
'definitionoptions'=>$definitionoptions,
'attachmentoptions'=>$attachmentoptions));
</code>
New code with element preparation:
<code php>
$entry = file_prepare_standard_editor($entry, 'definition', $definitionoptions, $context, 'glossary_entry', $entry->id);
$entry = file_prepare_standard_filemanager($entry, 'attachment', $attachmentoptions, $context, 'glossary_attachment', $entry->id);
$mform = new mod_glossary_entry_form(null, array(
'current'=>$entry,
'cm'=>$cm,
'glossary'=>$glossary,
'definitionoptions'=>$definitionoptions,
'attachmentoptions'=>$attachmentoptions));
</code>
Things to note:
* $entry in this case is simply a stdClass object which may either represent a new glossary entry or an existing one.
* $entry->id must be the unique identifier for the current object. If we are creating a new entry, it will be null, but in all cases it must be defined.
* These two functions (file_prepare_standard_editor and file_prepare_standard_filemanager) are shortcuts functions that take care of some of the tedious setting up for you, but they make a couple of assumptions:
*# You '''must''' name the form element as {element}_editor or {element}_filemanager (see next section)
*# You '''must''' have at least the following fields in the database: {element} and {element}summary, as described earlier in this documentation

We can now look at the upgrades needed in the form definition file.

=== Form definition ===
Previous code in mod/glossary/edit_form.php:
<code php>
$mform->addElement('htmleditor', 'definition', get_string('definition', 'glossary'), array('rows'=>20));
$mform->setType('definition', PARAM_RAW);
$mform->addRule('definition', null, 'required', null, 'client');
$mform->setHelpButton('definition', array('writing', 'richtext'), false, 'editorhelpbutton');
$mform->addElement('format');
// a bit further...
$this->set_upload_manager(new upload_manager('attachment', true, false, $COURSE, false, 0, true, true, false));
$mform->addElement('file', 'attachment', get_string('attachment', 'forum'));
$mform->setHelpButton('attachment', array('attachment', get_string('attachment', 'glossary'), 'glossary'));
</code>
New code:
<code php>
$definitionoptions = $this->_customdata['definitionoptions'];
$attachmentoptions = $this->_customdata['attachmentoptions'];
// a bit further...
$mform->addElement('editor', 'definition_editor', get_string('definition', 'glossary'), null, $definitionoptions);
$mform->setType('definition_editor', PARAM_RAW);
$mform->addRule('definition_editor', get_string('required'), 'required', null, 'client');
// a bit further...
$mform->addElement('filemanager', 'attachment_filemanager', get_string('attachment', 'glossary'), null, $attachmentoptions);
$mform->setHelpButton('attachment_filemanager', array('attachment2', get_string('attachment', 'glossary'), 'glossary'));
</code>

Note the following:
* The format element and the help button are no longer required for the HTML editor element
* The name of the form element needs to be changed by adding '_editor' or '_manager' to the original name. This is a naming convention that is used by a couple of functions we will look at shortly

=== Handling submitted data ===
The final step is to handle the submitted data properly, i.e. retrieve the files and save them to disk, associating them with the record we have just created (a glossary entry in our example). This happens in edit.php:

Previous code in edit.php:
<code php>
// Section that updates an entry:
$todb->id = $e;
$dir = glossary_file_area_name($todb);
if ($mform->save_files($dir) and $newfilename = $mform->get_new_filename()) {
$todb->attachment = $newfilename;
}

// Section that adds an entry:
if ($todb->id = insert_record("glossary_entries", $todb)) {
$e = $todb->id;
$dir = glossary_file_area_name($todb);
if ($mform->save_files($dir) and $newfilename = $mform->get_new_filename()) {
set_field("glossary_entries", "attachment", $newfilename, "id", $todb->id);
}
}
</code>
New code:
<code php>
// $todb was renamed to $entry, and the code was refactored
// so that the file-handling code is only used once for either an add or an update action.
// If an entry is being added, $DB->insert() has already been called, so we have a valid $entry->id
$entry = file_postupdate_standard_editor($entry, 'definition', $definitionoptions, $context, 'glossary_entry', $entry->id);
$entry = file_postupdate_standard_filemanager($entry, 'attachment', $attachmentoptions, $context, 'glossary_attachment', $entry->id);
// store the updated value values
$DB->update_record('glossary_entries', $entry);
</code>
Things to note:
* If you are adding a new record, you will still need to call update_record after calling the file_postupdate* functions

=== Gotchas ===
A few things to keep in mind:
* Make sure that you instantiate the moodle form before any call to $OUTPUT->header()

== See also ==

* [[Development:File API]]
* [[Development:Using the file API]]
* [[Development:Repository API]]
* [[Development:Portfolio API]]
* MDL-14589 - File API Meta issue

{{CategoryDeveloper}}
[[Category:Files]]
[[Category:Repositories]]

Comments 2.0

2010-05-11T03:21:04Z

Dongsheng:

==Objectives==

The goals of comments 2.0:

* Manage comments centrally
* Use a consistent approach for all comments throughout Moodle
* Easily integrate comments 2.0 with existing modules
* Works no matter Javascript is enabled or not

==Overview==

The comments 2.0 provides APIs to:
# Add comments
# Manage comments
# Delete comments

And provides a fancy ajax interface to add/delete comments without loading a new page.

==Comments database table==

{| class="nicetable"
|-
! Field
! Type
! Default
! Info
|-
| id
| int(10)
| auto-incrementing
| The unique ID for this comment.
|-
| userid
| int(10)
|
| who wrote this comment
|-
| contextid
| int(10)
|
| The context id defined in context table - identifies the instance of plugin owning the comment.
|-
| itemid
| int(10)
|
| Some plugin specific item id (eg. forum post, blog entry or assignment submission)
|-
| commentarea
| int(10)
|
| for example, in user profile, you can comment user's description or interests, but they share the same itemid(==userid), we need comment_area to separate them
|-
| timecreated
| int(10)
|
|
|-
| timemodified
| int(10)
|
|
|-
| content
| text
|
| content of comment
|}

==Use Comments API==

===Add an option to format_text function===

Using this format_text function will add a comment icon automatically at the end of the text:

For example, using the following code in the forum module will add a comment icon to every post:

<code php>
$to = new stdclass;
$cmt->contextid = $modcontext->id;
$cmt->area = 'format_post';
$cmt->itemid = $post->id;
$options->comments = $cmt;
echo format_text($post->message, $post->messageformat, $options, $course->id)."<hr />";
</code>

===Use comment class===
To use Comments API elsewhere, using following code:
<code php>
$options->area = 'database_entry';
$options->context = $context;
$options->itemid = $record->id;
$options->showcount = true;
$comment = new comment($options);
$comment->output(false);
</code>
If you are using comments API in module context, you'd better add pluginname option, it will help comments API find callback functions faster:
<code php>
$options->area = 'database_entry';
$options->pluginname = 'data';
$options->context = $context;
$options->itemid = $record->id;
$options->showcount = true;
$comment = new comment($options);
$comment->output(false);
</code>
==Comments API overview==

Generally speaking, only two functions you need to know to get comments 2.0 worked:
# Use comment::init to initialize comments 2.0
# Use $comment->output to display comments

The comment class has been implemented in comment/lib.php.
===class comment()===
====__construct($contextid, $comment_area, $itemid))====
Initialize class members

====init()====
It is a static function used to initialize comments, setting up languages, which must be called before html head printed

====output($return = false)====
Will print the html snippet for commenting interface, if set $return as true, it will return html string instead of printing out.

====print_comments($params = array())====
Used by non-javascript comment interface, will print a list of comments.

====add($content)====
Public instance funciton, add a comment to database, used in comment/comment_ajax.php

====count()====
Counting the number of comments

====delete($id)====
Delete a comment from database, used in comment/comment_ajax.php

====delete_comments====
Delete all comments in a specific contexts (like all comments belonging to a forum post)

==Javascript API==
Comments 2.0 implemented a YUI3 module M.core_comment to deal with the communication between browsers and moodle.
It can be found in comment/comment.js

Call M.core_comment.init will create an instance of CommentHelper class. You don't need to make any calls to this instance, it simply works out of box.

== Moodle modules callback ==
Comments API allows modules/blocks/blog to decide how comments display.

===Permission control===
Modules can implement a function named '''modname_comment_permissions''' to control post and view permission.

Blocks need to overwrite '''comment_permissions''' function of block_base.

Blog need to implement '''blog_comment_permissions''' function.

This function will return an array: array('post'=>true, 'view'=>true)

=== Check new added comment ===
The callback function allows you to change the comment content before inserting into database or reject this comment.

It takes two arguments, the comment object which contains comment details, and $params which contains context and course information.

Modules can implement a function named '''modname_comment_add'''.

Blocks need to overwrite '''comment_add''' function.

Blog need to implement '''blog_comment_add''' function.

This function should return a boolean value.

=== Filter/format comments ===
This callback allows modules check/format comments when user request to display comments.

It takes the same arguments as modname_comment_add

Modules can implement a function named '''modname_comment_display'''.

Blocks need to overwrite '''comment_display''' function.

Blog need to implement '''blog_comment_display''' function.

It will return the comment object.

=== Define a comment template ===
Modules can implement a function named '''modname_comment_template''', which allow modules define a comment template.
The template must have 4 embedding variables, ___id___, ___content___, ___time___, ___name___, they will be replaced with html id, comments content, comment time and commenter name

==See also==
* MDL-19118 - Comments 2.0 issue

Repository plugins

2010-05-11T03:00:33Z

Dongsheng:

A guide for developers on how to create a repository plugin.

== Introduction ==
===Prerequisites===
Before starting coding, it is necessary to know how to use repository administration pages and how to use the file picker.

There is a template attached to MDL-16543 which might be useful to help get you started.

===First steps===
# Create a folder for your plugin in ''moodle/repository/'' e.g. ''moodle/repository/myplugin''
# Create the following files and add them to the plugin folder:
#* ''repository.class.php''
#* ''icon.png'' (the icon displayed in the file picker)
#* "version.php"
# Create the language file ''repository_myplugin.php'' and add it to the plugin folder, keeping the following folder structure:
#*''moodle/repository/myplugin/lang/en_utf8/repository_myplugin.php'' or ''moodle/lang/en_utf8/repository_myplugin.php''
# Create access.php and upgrade scripts

===Overview===

The 3 different parts to write
# Administration - You can customise the way administrators and users can configure their repositories.
# File picker integration - The core of your plugin, it will manage communication between Moodle and the repository service, and also the file picker display.
# I18n - Internationalization should be done at the same time as you're writing the other parts.

==Administration APIs==

As an example, let's create a Flickr plugin for accessing a public flickr account. The plugin will be called "Flickr Public".

Firstly the skeleton:

<code php>
<?php
/**
* repository_flickr_public class
* Moodle user can access public flickr account
*
* @license http://www.gnu.org/copyleft/gpl.html GNU Public License
*/
class repository_flickr_public extends repository {
}
?>
</code>

Then consider the question "What does my plugin do?"

In the Moodle file picker, we want to display some flickr public repositories directly linked to a flickr public account. For example ''My Public Flickr Pictures'', and also ''My Friend's Flickr Pictures''. When the user clicks on one of these repositories, the public pictures are displayed in the file picker.

In order to access to a flickr public account, the plugin needs to know the email address of the Flickr public account owner. So the administrator will need to set an email address for every repository. Let's add an "email address" setting to every repository.

<code php>
//We tell the API that the repositories have specific settings: "email address"
public static function get_instance_option_names() {
return array('email_address');
}

//We add an "email address" text box to the create/edit repository instance Moodle form
public function instance_config_form(&$mform) {
$mform->addElement('text', 'email_address', get_string('emailaddress', 'repository_flickr_public'));
$mform->addRule('email_address', get_string('required'), 'required', null, 'client');
}
</code>

So at this moment all our Flickr Public Repositories will have a specific email address. However this is not enough. In order to communicate with Flickr, Moodle needs to know a Flickr API key (http://www.flickr.com/services/api/). This API key is the same for any repository. We could add it with the email address setting but the administrator would have to enter the same API key for every repository. Hopefully the administrator can add settings to the plugin level, impacting all repositories. The code is similar the repository instance settings:
<code php>
//We tell the API that the repositories have general settings: "api_key"
public static function get_type_option_names() {
return array('api_key');
}

//We add an "api key" text box to the create/edit repository plugin Moodle form (also called a Repository type Moodle form)
public function type_config_form(&$mform) {
//the following line is needed in order to retrieve the API key value from the database when Moodle displays the edit form
$api_key = get_config('flickr_public', 'api_key');
$mform->addElement('text', 'api_key', get_string('apikey', 'repository_flickr_public'),
array('value'=>$api_key,'size' => '40'));
$mform->addRule('api_key', get_string('required'), 'required', null, 'client');
}
</code>

Have we finished yet?

Yes! We have created everything necessary for the administration pages. But let's go further. It would be good if the user can enter any "Flickr public account email address" in the file picker. In fact we want to display in the file picker a Flickr Public repository that the Moodle administrator can never delete. Let's add:

<code php>
//this function is only called one time, when the Moodle administrator add the Flickr Public Plugin into the Moodle site.
public static function plugin_init() {
//here we create a default repository instance. The last parameter is 1 in order to set the instance as readonly.
repository_static_function('flickr_public','create', 'flickr_public', 0, get_system_context(),
array('name' => 'default instance','email_address' => null),1);
}
</code>

That's all - the administration part of our Flickr Public plugin is done. For your information, Box.net, Flickr, and Flickr Public all have similar administration APIs.

===Functions===
All of the following functions are optional. If they're not implemented, your plugin will not have manual settings and will have only one instance displayed in the File Picker (The repository API creates this unique instance when the administrator add the plugin).

==== get_instance_option_names====
''This function must be declared static'' 
Return an array of strings. These strings are setting names. These settings are specific to an instance.
If the function returns an empty array, the API will consider that the plugin displays only one repository in the file picker.
Parent function returns an empty array.

====instance_config_form(&$mform)====
This is for modifying the Moodle form displaying the settings specific to an instance.

For example, to add a required text box called email_address:
<code php>
$mform->addElement('text', 'email_address', get_string('emailaddress', 'repository_flickr_public'));
$mform->addRule('email_address', $strrequired, 'required', null, 'client');
</code>

''Note: ''mform'' has by default a name text box (cannot be removed).''

Parent function does nothing.

====get_type_option_names====
''This function must be declared static'' 
Return an array of string. These strings are setting names. These settings are shared by all instances.
Parent function return an empty array.

====type_config_form(&$mform)====
This is for modifying the Moodle form displaying the plugin settings.
Similar to ''instance_config_form(&$mform)''

====plugin_init()====
''This function must be declared static'' 
This function is called when the administrator adds the plugin. So unless the administrator deletes the plugin and re-adds it, it should be called only once.
Parent function does nothing.

==File picker APIs==
=== Quick Start ===
'''To be completed''' 
First of all, the File Picker using intensively Ajax you will need a easy way to debug. Install FirePHP (MDL-16371) and make it works. It will save you a lot of time. (You might give the [http://moodle.org/mod/forum/discuss.php?d=119961 FirePHP plugin for Moodle] a try, it's still work in progress, though.)

Your first question when you write your plugin specification is 'Does the user need to log-in'? 
.....

For most of plugins, you need to establish a connection with the remote repository. This connection can be done into the get_listing(), constructor() function... 
.....

You wanna display a list of files once the user is logged 
.... get_listing() .....

You wanna retrieve the file that the user selected 
....

Optional question that you should ask yourself is 'Does the user can execute a search' 
.... search() ....

===Functions you *MUST* override===
====__construct====
You may initialize your plugin here, such as:
# Get options from database
# Get user name and password from HTTP POST

====get_listing($path="", $page="")====
This function will return a list of files, the list must be a array like this:
<code php>
$list = array(
//this will be used to build navigation bar
'path'=>array(array('name'=>'root','path'=>'/'), array('name'=>'subfolder', 'path'=>'/subfolder')),
'manage'=>'http://webmgr.moodle.com',
'list'=> array(
array('title'=>'filename1', 'date'=>'01/01/2009', 'size'=>'10MB', 'source'=>'http://www.moodle.com/dl.rar'),
array('title'=>'folder', 'date'=>'01/01/2009', 'size'=>'0', 'children'=>array())
)
);
</code>
'''The full specification of list element:'''
<code php>
array(
// Used to build navegation bar, so you need to include all parents folders
// array(array('name'=>'root','path'=>'/'), array('name'=>'subfolder', 'path'=>'/subfolder'))
'path' => (array) this will be used to build navigation bar
// dynload tells file picker to fetch list dynamically, when user click
// the folder, it will send a ajax request to server side.
// if you are using pagination, 'page' and 'pages' parameters should be used
// and note, you'd better don't use pagination and page at the same time
'page' => (int) which page is this list
'pages' => (pages) how many pages
'dynload' => (bool) use dynamic loading,
// will display a link in file picker
'manage' => (string) url of the file manager,
// set to true, the login link will be removed from file picker
'nologin' => (bool) requires login,
// set to true, the search link will be removed from file picker
'nosearch' => (bool) no search link,
// set this option will display a upload form in file picker
// only used in upload plugin currently
'upload' => array( // upload manager
'label' => (string) label of the form element,
'id' => (string) id of the form element
),
// file picker will build a file tree according this
// list
'list' => array(
array( // file
'title' => (string) file name,
'shorttitle' => (string) optional, if you prefer to display a short title
'date' => (string) file last modification time, usually userdate(...),
'size' => (int) file size,
'thumbnail' => (string) url to thumbnail for the file,
'thumbnail_width' => (int) the width of the thumbnail image,
'source' => plugin-dependent unique path to the file (id, url, path, etc.),
'url'=> the accessible url of file
),
array( // folder - same as file, but no 'source'.
'title' => (string) folder name,
'shorttitle' => (string) optional, if you prefer to display a short title
'path' => (string) path to this folder
'date' => (string) folder last modification time, usually userdate(...),
'size' => 0,
'thumbnail' => (string) url to thumbnail for the folder,
'children' => array( // an empty folder needs to have 'children' defined, but empty.
// content (files and folders)
)
),
)
)
</code>
Dynamically loading
Some repositories contain many files which cannot load in one time, in this case, we need dynamically loading to fetch them step by step, files in subfolder won't be listed until user click the folder in file picker treeview.

As a plug-in developer, if you set dynload flag as '''true''', you should return files and folders (set children as a null array) in current path instead of building the whole file tree.

Example of dynamically loading
See [http://cvs.moodle.org/moodle/repository/alfresco/repository.class.php?view=log Alfresco] plug-in

===Functions you can override===
====print_login====
This function will help to print a login form, for the Ajax file picker, this function will return a
PHP array to define this form.
<code php>
public function print_login(){
if ($this->options['ajax']) {
$user_field->label = get_string('username', 'repository_boxnet').': ';
$user_field->id = 'box_username';
$user_field->type = 'text';
$user_field->name = 'boxusername';
$user_field->value = $ret->username;

$passwd_field->label = get_string('password', 'repository_boxnet').': ';
$passwd_field->id = 'box_password';
$passwd_field->type = 'password';
$passwd_field->name = 'boxpassword';

$ret = array();
$ret['login'] = array($user_field, $passwd_field);
// if you are going to rename submit button label, use this option
//$ret['login_btn_label'] = get_string('submit_btn_label');
// if you are going to display a search form instead of login form
// set this option to true
//$ret['login_search_form'] = true;
return $ret;
}
}
</code>
This will help to generate a form by file picker which contains user name and password input elements.

If your plugin don't require logging in, you don't need to override it, it will call get_listing to list files automatically by default.
====check_login====
This function will return a boolean value to tell Moodle whether the user has logged in.
By default, this function will return true.
====logout====
When a user clicks the logout button in file picker, this function will be called. You may clean up the session or disconnect the connection with remote server here.
====print_search====
When a user clicks the search button on file picker, this function will be called to return a search form. By default, it will create a form with single search bar - you can override it to create a advanced search form.
====search====
This function will do the searching job. You can obtain the POST parameters from the from the form you created in print_search function
This function will return a file list exactly like the one from get_listing.
====get_file====
When a user clicks the "Get" button to transfer the file, this function will be called. Basically, it will download a file to Moodle - you can override it to modify the file then move it to a better location.
====get_name====
This function will return the name of the repository instance.

== I18n - Internationalization ==
These following strings are required in ''moodle/repository/myplugin/lang/en_utf8/repository_myplugin.php'' or ''moodle/lang/en_utf8/repository_myplugin.php'':

<code php>
$string['configplugin'] = 'Flickr Public configuration';
$string['repositorydesc'] = 'A Flickr public repository';
$string['repositoryname'] = 'Flickr Public';
</code>

== Standard repository plugins ==
This is the functional specification list of the officially supported repository plugins.
For each plugins, the two mains part we are interested in are:
* How do I administrate the plugin? See [[Development:Repository_Administration_Specification| Repository Administration Specification - UC001-3]]
* How do I set up an account for this repository? See [[Development:Repository_Interface_for_Moodle/Course/User| Repository Interface for Moodle/Course/User]]

=== Functional specifications ===
*[[Development:Box.net Repository Plugin|Box.net Repository Plugin]]
*[[Development:Flickr Repository Plugin|Flickr Repository Plugin]]
*[[Development:Moodle Repository Plugin|Remote Moodle Repository Plugin]]

==See also==

*[[Development:Repository API| Repository API]]
*[[Development:Repository_Interface_for_Moodle/Course/User| Repository Interface for Moodle/Course/User]]
*[[QA:Use Case Number Attribution| Use Case Number Attribution]]
* MDL-16543 - A list of officially supported repository plugins
* MDL-16543 - Template plugin for developers
[[Category:Repositories]]

Broken/Repository API

2010-05-11T02:59:03Z

Dongsheng: fixed syntax

{{Moodle_2.0}}

The page is open for everyone so everyone can help correct mistakes and help with the evolution of this document. However, if you have questions to ask, problems to report or major changes to suggest, please add them to the [[Development_talk:Repository_API|page comments]], or start a discussion in the [http://moodle.org/mod/forum/view.php?id=1807 Repositories forum]. We'll endeavour to merge all such suggestions into the further development and fix all kinds of problems.

Note that parts of this document have been now split off into a separate [[Development:File_API]]

==Objectives==

# Allow all Moodle users to easily bring content into Moodle from external repositories
# Provide a consistent interface to any external repository, for any Moodle module

==Use cases==

===Teacher adding an external file as a new resource===

# Teacher wants to add a new resource to a course
# Teacher clicks the "Choose a resource" button
# Teacher is presented with a simple file picker to choose a file (with a menu to switch between multiple configured repositories)
# Teacher chooses a file in an external repository
# File is COPIED into Moodle and stored by the resource module
# File is marked as owned by that user
# Whenever someone wants to view that file, the resource module controls access (see [[Development:File API]] )

===Teacher linking to an external file as a new resource (think video repository) ===

# Teacher wants to display a file in the repository
# Teacher clicks the "Choose a resource" button
# Teacher is presented with a simple file picker to choose a file (with a menu to switch between multiple configured repositories)
# Teacher chooses a file in an external repository
# Link to the file is COPIED into Moodle and stored by the resource module
# Link is marked as owned by that user
# Whenever someone wants to follow that link, the resource module controls access (see [[Development:File API]] )

===Student submitting an assignment===
# Student needs to submit an assignment and presses the "Choose files" button
# Student sees a "file picker" where they can see files listed on any of several configured repositories ([https://docs.moodle.org/en/Image:Filepicker_login.jpg file picker login], [https://docs.moodle.org/en/Image:Filepicker_browser.jpg file picker browser], [https://docs.moodle.org/en/Image:Filepicker_search.jpg file picker search])
# Student chooses MySpace from the list
# Student is prompted to enter MySpace username/password (if admin allows it, a checkbox could be there to "remember this for next time" but remember security)
# Student sees their files in MySpace and chooses one or more
# Files are copied from MySpace to Moodle
# Assignment module controls the permissions so that only the Student and assignment graders can see the file (other students would not have permission).

===Student attaching an image to a forum===
# Student needs to attach an image and presses the "Choose files" button in the posting screen
# Student sees a "file picker" where they can see files listed on any of several configured repositories
# Student chooses Mahara from the list
# Student is prompted to enter Mahara username/password
# Student sees their files in Mahara and chooses one image
# Image is copied to Moodle
# Image file is attached to forum post by Forum module (by reference)
# Forum module controls permissions so that anyone who can read that forum can see that file

===Student attaching the same image in another forum===

# Student needs to submit an assignment and presses the "Choose files" button
# Student sees a "file picker" where they can see files listed on any of several configured repositories
# Student chooses "Local files" from the list and sees all the files they've permission to use
# A COPY of the image file is attached to forum post by Forum module
# Forum module controls access to this file.

Please add more use cases in this same format

==Mock screenshots==
When you first call up the file picker and choose a repository, you might be asked to log in (if saving of passwords is not allowed):

[[Image:Filepicker_login.jpg]]

Browsing files could look something like this:

[[Image:Filepicker_browser.jpg]]

And you can also search:

[[Image:Filepicker_search.jpg]]

==General architecture==

Each repository plugin (a standard Moodle plugin stored under /repository/xxx) will subclass the standard API and override methods specific to that repository.

As is usual in Moodle, there will be admin settings to disable/enable certain repository plugins as standard, as well as user settings so that users can add their own personal repositories to the standard list (eg [http://briefcase.yahoo.com Yahoo Briefcase] or [http://docs.google.com Google Docs]) and to select their default repository.

Once a repository has been used the file will usually be copied into Moodle there and then. However there will also be options to:
* only return the URL to the file if it's desired to keep it external (but this does present security and integrity risks), or
* refresh the local file copy regularly and automatically
* refresh the file manually if desired

Once in Moodle, it is subject to the [[Development:File API]] for access control like any other file.

==Repository requirements==

From the Moodle point of view, each repository is just a hierarchy of nodes.

The repository MUST provide:
# A URI to download each node (eg file).
# A list of the nodes (eg files and directories) under a given node (eg directory). This allows Moodle to construct a standard browse interface (much like a standard OS file picker).

The repository can OPTIONALLY:
# Require some authentication credentials
# Provide more metadata about each node (mime type, size, dates, related files, dublin core stuff, etc)
# Describe a search facility (so that Moodle can construct a search form)
# Provide copyright and usage rules (or just information about the rules)

==Repository plugins==

Some plugins I'd like to see developed for the first version are:
* box - an interface to [http://box.net box.net]
* mahara - an interface to a Mahara installation
* Server Files - very similar to the current course-based file manager, except user-based
* Remote Moodle - an interface to another Moodle site, accessed over a secure mnet connection
* googledocs - an interface to [http://docs.google.com Google Docs]
* s3 - an interface to [http://www.amazon.com/gp/browse.html?node=16427261 Amazon S3]
* flickr - an interface to [http://flickr.com flickr]
* WebDAV - to access arbitrary external WebDAV servers
* merlot - an interface to the learning materials in [http://www.merlot.org/merlot/materials.htm Merlot.org]
* File System - a plugin to list files on local file system, of course, you can mount remote files to this local directory
* youtube - an interface to [http://youtube.com YouTube]
* jsr170 - an interface that can talk to anything that supports jsr170 (eg [http://www.alfresco.com/ Alfresco])
* oki - an OKI emulator allowing us to access things with OKI interfaces,like [http://www.fedora.info/ Fedora]
* briefcase - an interface to [http://briefcase.yahoo.com/ Yahoo Briefcase]
* myspace - an interface to MySpace files (perhaps via [http://www.programmableweb.com/api/myspace this MySpace API])
* skydrive - an interface to Microsoft's [http://skydrive.live.com/ SkyDrive] files
* facebook - an interface to Facebook files
* [http://www.dspace.org/ Dspace] - a repository from MIT
* DOOR - another popular open source repository
* SMB shares - An interface for windows shares e.g. personal folders on network drives. Would need to link with LDAP as usernames will often be wholly/partially the same as network folder names. This could be done using SAMBA, but would also need to work on windows machines natively. See [http://moodle.org/mod/data/view.php?d=13&rid=991 this block] for a linux implementation.

==Tables==

=== repository ===

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''id'''
|int(10)
|
|autoincrementing

|-
|'''type'''
|varchar(255)
|
|The type of the repository

|-
|'''visible'''
|tinyint(1)
|
|

|-
|sortorder
|int(10)
|
|
|}

=== repository_instances ===

This table contains one entry for every configured external repository instance.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''id'''
|int(10)
|
|autoincrementing

|-
|name
|varchar 255
|
|A custom name for this repository (non-unique)

|-
|'''typeid'''
|int(10)
|
|The id of repository type

|-
|'''userid'''
|int(10)
|
|The person who created this repository instance

|-
|'''contextid'''
|int(10)
|
|The context that this repository is available to ( = system context for site-wide ones)

|-
|username
|varchar(255)
|
|username to log in with, if required (almost never!)

|-
|password
|varchar(255)
|
|password to log in with, if required (almost never!)

|-
|timecreated
|int(10)
|
|The time this repository was created

|-
|timemodified
|int(10)
|
|The last time the repository was modified
|}

=== repository_instance_config ===

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''id'''
|int(10)
|
|autoincrementing

|-
|'''instanceid'''
|int(int)
|
|

|-
|'''name'''
|varchar(255)
|
|

|-
|value
|Text
|
|
|}

===File types===

The context at which someone is inserting a file may require certain file types (eg uploading a new user profile image is only looking for images).

To support this, the calling code needs to be able to specify the required mimetypes, and the listing code should be able to filter the results based on these mimetypes. Ideally the repository itself can do the filtering for ultimate speed (though not all repositories will support this).

We will have to develop special new mimetypes for Moodle files like backups (application/vnd.moodle.backup) and IMS learning design (application/vnd.moodle.imsld) etc

==Technical walkthrough==

(See also the functional spec for the [[Development:Repository_File_Picker]] )

There are two main cases where the repository API will be used: as part of a Moodleform to add a file and as part of the HTML editor to add a media element into some HTML). We also have to cater for the using Moodleforms without Javascript.

In all of these cases the files will be uploaded to Moodle while using the file picker dialog and stored in a temporary file area owned by the currently active user. It is only AFTER the submission of the entire Moodleform that we will know the full context, itemids to store the file properly, so at this time the file will be copied into the correct filearea.

===Case 1: As part of a Moodleform with Javascript===

1. Moodle module code calls a "filepicker" moodleform item whenever a file is required, which includes the following information to pass to the File API:

eg $mform->addElement('filepicker', 'uniqueelementid', $fullname, $data)

2. When rendering the form, Moodle will display a read-only filename field with an '''"Add file"''' button next to it. There will also be a hidden field to store a file reference later (this is what actually gets used, the filename field is just for users to see something).

3. When the add file button is pressed, the form will be "replaced" in the page by a larger resizeable area containing an AJAX file picker. (After picking the display can be closed). (There could be a user option to make this a popup window instead, if required)

4. The AJAX file picker interface will list all the active repositories as a menu, and list files in one of several formats (like Windows/Mac/Linux): Details, Names, Icons.

5. For each plugin, the AJAX interface will prompt the user to login first (if required) asking the plugin to log in behind the scenes. It'll also ask the plugin to return listing data in response to clicks and searches.

6. Finally, when the user selects a file and clicks the "Select" button, the AJAX interface will trigger a method in the plugin that will fetch the file and call the File Storage API to '''store''' the file using the '''uniqueelementid''' and the current user info. While this is happening, the interface should show some sort of progress bar (ideally) or at least a "loading file" image/sign/message.

7. After a file has finally been selected we will have a file ID which we can pass back to the original Moodle form (to the hidden field named '''uniqueelementid_formid'''). The picker can then rename the read-only filename field before it hides itself.

8. Submitting the form will trigger the mform processing for this field, which will check fields, create things in the module etc. Once this has been finally successful the developer must call an mform function to "fix" the info for each file and "move" it into the module file area:

eg $mform->store_local_file('uniqueelementid', $context, $filearename, $itemid, $filepath);

9. Cron jobs in File Storage api should automatically delete any files in the user's tempfile area that are older than 7 days or move them into a trash can in the user's file area (perhaps).

===Case 2: As part of a Moodleform without Javascript===

Steps 1-2 are the same as for the case with Javascript.

3. The add file button is a submit button for the form with a different value. When the add file button is pressed,
* the whole form will be ''submitted'' to the original location (but with a different submit button value)
* moodleforms get_data() will detect this is a "repository save" and can save the full POST info in the current session tagged with the id of the openfile element, together with the URL to return to
* moodleforms get_data() then redirects the user to a new page showing the main picker interface

4. The file picker interface will have to be a completely new and separate interface from the AJAX one. It could be a long hierarchy listing, or reload a lot.

5. Finally, when the user selects a file and submits using the "Select" button to picker.php, it will trigger a method in the plugin that will fetch the file and call the [[Development:File_API|File API]] to store the file using the filearea and context information we already had. While this is happening, the interface can show some sort of progress bar (ideally) or at least a "loading file" image/sign/message.

6. After this, picker.php will redirect/continue back to the original form page. The form can be constructed as usual, however, when the form is rendered using display() method moodleforms should now look for relevant saved content in the session and use that to override any content in the form (and then delete the saved info in the session).

Steps 8-9 are the same as for the case with Javascript.

===Case 3: As part of a HTML editor===

The key thing here is a move away from storing any absolute URLs to files in our HTML texts. Instead we'll store relative names.

1. The moodleform for a textarea (HTML editor) will require a path to the filearea associated with this HTML. eg '''wwwroot/pluginfile.php/13/content/0/'''. This would have to be the user_draft area if the filearea doesn't exist yet eg '''wwwroot/draftfile.php/userid/tempfile/uniquelementid'''

2. All textarea content will also need to have str_replace done on it to replace @@pluginfile@@/somefilenames.jpg in the content to use this path so that it comes up right in the editor. (Note this also needs to be done on every format_text command too when showing this text.)

3. The path parameter also needs to be added to the editor configuration in the current page.

4. Editor plugins can be modified to look for these variables in the editor configuration.

5. When adding an image or other media element, the same AJAX repository picker will show up as a popup div to allow people to pick from any repository and choose files to download. The repository picker is responsible for downloading the file in real-time, storing it as a user temporary file if the filearea doesn't already exist, prefixing the supplied path to the filename and returning a URL back to the dialog text input before closing.

6. On submission, and after the HTML is stored, we might now have a new permanent filearea, so we'll need to update any associated temporary files to make sure they have the proper file area information.

==Repository plugins==

Each repository plugin is required to contain the following elements:

===class repository()===

This class implements the interface to a particular repository, for browsing, selecting and updating files. The base class (repository) is defined in /repository/lib.php, while each repository defines an inherited class (eg repository_alfresco) in /repository/repositoryname/repository.class.php

Repositories can redefine any of these methods as required (and in some instances, MUST redefine them):

====__construct($repositoryid, $contextid, $options=array(), $readonly)====

'''MUST''' redefine

Accept necessary parameters, and do initialization of repository.

====get_file($url, $file = '')====

Given a URL, download a file from there, save the file in a temporary directory.

====get_link($info)====
Get the url of external resource

====get_listing($path='/', $page='''''''')====

Given a path, and perhaps a search, get a listing of files. In the case of AJAX file picker, this function should return json format Javascript array.

====search($keyword)====
Search repository by given keyword, it will return an array of the same format of get_listing

====print_login()====

Show the login screen, if required. In the case of AJAX file picker, this function should return json format array which defined the login form.

====print_search====

Print the search form, it will return a json string

====get_meta()====
Return information for creating ajax request, it is private function, you don't need to rewrite it.

====create()====
Create an instance

====delete()====
Delete this instance from `repository` table

====hide()====
Hide a repository instance from file picker list

====set_option()====
set options in data1-data5 fields, can be overrided

====get_option()====
get option list or a specific option from database

====get_type_option_names()====
If this plugin needs admin settings, please refine this function to return option names.

====type_config_form()====
If get_type_option_names return non empty array, this function '''MUST''' redefine, it will help to build the setting form.

====get_instance_option_names()====
If plugin instance needs settings, this function will return instance option names.

====instance_config_form()====
If get_instance_option_names return non empty array, this function '''MUST''' redefine, it will help to build the instance setting form.

====supported_filetypes()====
What file types are supported by this repository plugin, it will return an array, the file type name is defined in a [http://freemind.sourceforge.net/wiki/index.php/Main_Page freemind] file in lib/file/file_types.mm

====supported_returntypes()====
The repository plugin could support external link or copying files to moodle. If the plugin support file link only, developer should override this function to return FILE_EXTERNAL, if plugin support copying file only, it should return FILE_INTERNAL, by default, plugin supports both.

====filter()====
Filter file listing to exclude specific file types

===icon.png===

A logo that represents the repository. Ideally square but we should handle all sizes.

==See also==

* [[Development:Repository Administration Specification]]
* [[Development:Repository Interface for Moodle/Course/User]]
* [[Development:Repository plugins]]
* [[Development:Repository File Picker]]
* [[Development:File API]]
* [[Development:Portfolio API]]
* MDL-13766 and MDL-16543 Repository API Meta issues

[[Category:Repositories]]

[[ja:開発:リポジトリAPI]]

Broken/Repository API

2010-05-11T02:58:06Z

Dongsheng: update

{{Moodle_2.0}}

The page is open for everyone so everyone can help correct mistakes and help with the evolution of this document. However, if you have questions to ask, problems to report or major changes to suggest, please add them to the [[Development_talk:Repository_API|page comments]], or start a discussion in the [http://moodle.org/mod/forum/view.php?id=1807 Repositories forum]. We'll endeavour to merge all such suggestions into the further development and fix all kinds of problems.

Note that parts of this document have been now split off into a separate [[Development:File_API]]

==Objectives==

# Allow all Moodle users to easily bring content into Moodle from external repositories
# Provide a consistent interface to any external repository, for any Moodle module

==Use cases==

===Teacher adding an external file as a new resource===

# Teacher wants to add a new resource to a course
# Teacher clicks the "Choose a resource" button
# Teacher is presented with a simple file picker to choose a file (with a menu to switch between multiple configured repositories)
# Teacher chooses a file in an external repository
# File is COPIED into Moodle and stored by the resource module
# File is marked as owned by that user
# Whenever someone wants to view that file, the resource module controls access (see [[Development:File API]] )

===Teacher linking to an external file as a new resource (think video repository) ===

# Teacher wants to display a file in the repository
# Teacher clicks the "Choose a resource" button
# Teacher is presented with a simple file picker to choose a file (with a menu to switch between multiple configured repositories)
# Teacher chooses a file in an external repository
# Link to the file is COPIED into Moodle and stored by the resource module
# Link is marked as owned by that user
# Whenever someone wants to follow that link, the resource module controls access (see [[Development:File API]] )

===Student submitting an assignment===
# Student needs to submit an assignment and presses the "Choose files" button
# Student sees a "file picker" where they can see files listed on any of several configured repositories ([https://docs.moodle.org/en/Image:Filepicker_login.jpg file picker login], [https://docs.moodle.org/en/Image:Filepicker_browser.jpg file picker browser], [https://docs.moodle.org/en/Image:Filepicker_search.jpg file picker search])
# Student chooses MySpace from the list
# Student is prompted to enter MySpace username/password (if admin allows it, a checkbox could be there to "remember this for next time" but remember security)
# Student sees their files in MySpace and chooses one or more
# Files are copied from MySpace to Moodle
# Assignment module controls the permissions so that only the Student and assignment graders can see the file (other students would not have permission).

===Student attaching an image to a forum===
# Student needs to attach an image and presses the "Choose files" button in the posting screen
# Student sees a "file picker" where they can see files listed on any of several configured repositories
# Student chooses Mahara from the list
# Student is prompted to enter Mahara username/password
# Student sees their files in Mahara and chooses one image
# Image is copied to Moodle
# Image file is attached to forum post by Forum module (by reference)
# Forum module controls permissions so that anyone who can read that forum can see that file

===Student attaching the same image in another forum===

# Student needs to submit an assignment and presses the "Choose files" button
# Student sees a "file picker" where they can see files listed on any of several configured repositories
# Student chooses "Local files" from the list and sees all the files they've permission to use
# A COPY of the image file is attached to forum post by Forum module
# Forum module controls access to this file.

Please add more use cases in this same format

==Mock screenshots==
When you first call up the file picker and choose a repository, you might be asked to log in (if saving of passwords is not allowed):

[[Image:Filepicker_login.jpg]]

Browsing files could look something like this:

[[Image:Filepicker_browser.jpg]]

And you can also search:

[[Image:Filepicker_search.jpg]]

==General architecture==

Each repository plugin (a standard Moodle plugin stored under /repository/xxx) will subclass the standard API and override methods specific to that repository.

As is usual in Moodle, there will be admin settings to disable/enable certain repository plugins as standard, as well as user settings so that users can add their own personal repositories to the standard list (eg [http://briefcase.yahoo.com Yahoo Briefcase] or [http://docs.google.com Google Docs]) and to select their default repository.

Once a repository has been used the file will usually be copied into Moodle there and then. However there will also be options to:
* only return the URL to the file if it's desired to keep it external (but this does present security and integrity risks), or
* refresh the local file copy regularly and automatically
* refresh the file manually if desired

Once in Moodle, it is subject to the [[Development:File API]] for access control like any other file.

==Repository requirements==

From the Moodle point of view, each repository is just a hierarchy of nodes.

The repository MUST provide:
# A URI to download each node (eg file).
# A list of the nodes (eg files and directories) under a given node (eg directory). This allows Moodle to construct a standard browse interface (much like a standard OS file picker).

The repository can OPTIONALLY:
# Require some authentication credentials
# Provide more metadata about each node (mime type, size, dates, related files, dublin core stuff, etc)
# Describe a search facility (so that Moodle can construct a search form)
# Provide copyright and usage rules (or just information about the rules)

==Repository plugins==

Some plugins I'd like to see developed for the first version are:
* box - an interface to [http://box.net box.net]
* mahara - an interface to a Mahara installation
* Server Files - very similar to the current course-based file manager, except user-based
* Remote Moodle - an interface to another Moodle site, accessed over a secure mnet connection
* googledocs - an interface to [http://docs.google.com Google Docs]
* s3 - an interface to [http://www.amazon.com/gp/browse.html?node=16427261 Amazon S3]
* flickr - an interface to [http://flickr.com flickr]
* WebDAV - to access arbitrary external WebDAV servers
* merlot - an interface to the learning materials in [http://www.merlot.org/merlot/materials.htm Merlot.org]
* File System - a plugin to list files on local file system, of course, you can mount remote files to this local directory
* youtube - an interface to [http://youtube.com YouTube]
* jsr170 - an interface that can talk to anything that supports jsr170 (eg [http://www.alfresco.com/ Alfresco])
* oki - an OKI emulator allowing us to access things with OKI interfaces,like [http://www.fedora.info/ Fedora]
* briefcase - an interface to [http://briefcase.yahoo.com/ Yahoo Briefcase]
* myspace - an interface to MySpace files (perhaps via [http://www.programmableweb.com/api/myspace this MySpace API])
* skydrive - an interface to Microsoft's [http://skydrive.live.com/ SkyDrive] files
* facebook - an interface to Facebook files
* [http://www.dspace.org/ Dspace] - a repository from MIT
* DOOR - another popular open source repository
* SMB shares - An interface for windows shares e.g. personal folders on network drives. Would need to link with LDAP as usernames will often be wholly/partially the same as network folder names. This could be done using SAMBA, but would also need to work on windows machines natively. See [http://moodle.org/mod/data/view.php?d=13&rid=991 this block] for a linux implementation.

==Tables==

=== repository ===

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''id'''
|int(10)
|
|autoincrementing

|-
|'''type'''
|varchar(255)
|
|The type of the repository

|-
|'''visible'''
|tinyint(1)
|
|

|-
|sortorder
|int(10)
|
|
|}

=== repository_instances ===

This table contains one entry for every configured external repository instance.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''id'''
|int(10)
|
|autoincrementing

|-
|name
|varchar 255
|
|A custom name for this repository (non-unique)

|-
|'''typeid'''
|int(10)
|
|The id of repository type

|-
|'''userid'''
|int(10)
|
|The person who created this repository instance

|-
|'''contextid'''
|int(10)
|
|The context that this repository is available to ( = system context for site-wide ones)

|-
|username
|varchar(255)
|
|username to log in with, if required (almost never!)

|-
|password
|varchar(255)
|
|password to log in with, if required (almost never!)

|-
|timecreated
|int(10)
|
|The time this repository was created

|-
|timemodified
|int(10)
|
|The last time the repository was modified
|}

=== repository_instance_config ===

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''id'''
|int(10)
|
|autoincrementing

|-
|'''instanceid'''
|int(int)
|
|

|-
|'''name'''
|varchar(255)
|
|

|-
|value
|Text
|
|
|}

===File types===

The context at which someone is inserting a file may require certain file types (eg uploading a new user profile image is only looking for images).

To support this, the calling code needs to be able to specify the required mimetypes, and the listing code should be able to filter the results based on these mimetypes. Ideally the repository itself can do the filtering for ultimate speed (though not all repositories will support this).

We will have to develop special new mimetypes for Moodle files like backups (application/vnd.moodle.backup) and IMS learning design (application/vnd.moodle.imsld) etc

==Technical walkthrough==

(See also the functional spec for the [[Development:Repository_File_Picker]] )

There are two main cases where the repository API will be used: as part of a Moodleform to add a file and as part of the HTML editor to add a media element into some HTML). We also have to cater for the using Moodleforms without Javascript.

In all of these cases the files will be uploaded to Moodle while using the file picker dialog and stored in a temporary file area owned by the currently active user. It is only AFTER the submission of the entire Moodleform that we will know the full context, itemids to store the file properly, so at this time the file will be copied into the correct filearea.

===Case 1: As part of a Moodleform with Javascript===

1. Moodle module code calls a "filepicker" moodleform item whenever a file is required, which includes the following information to pass to the File API:

eg $mform->addElement('filepicker', 'uniqueelementid', $fullname, $data)

2. When rendering the form, Moodle will display a read-only filename field with an '''"Add file"''' button next to it. There will also be a hidden field to store a file reference later (this is what actually gets used, the filename field is just for users to see something).

3. When the add file button is pressed, the form will be "replaced" in the page by a larger resizeable area containing an AJAX file picker. (After picking the display can be closed). (There could be a user option to make this a popup window instead, if required)

4. The AJAX file picker interface will list all the active repositories as a menu, and list files in one of several formats (like Windows/Mac/Linux): Details, Names, Icons.

5. For each plugin, the AJAX interface will prompt the user to login first (if required) asking the plugin to log in behind the scenes. It'll also ask the plugin to return listing data in response to clicks and searches.

6. Finally, when the user selects a file and clicks the "Select" button, the AJAX interface will trigger a method in the plugin that will fetch the file and call the File Storage API to '''store''' the file using the '''uniqueelementid''' and the current user info. While this is happening, the interface should show some sort of progress bar (ideally) or at least a "loading file" image/sign/message.

7. After a file has finally been selected we will have a file ID which we can pass back to the original Moodle form (to the hidden field named '''uniqueelementid_formid'''). The picker can then rename the read-only filename field before it hides itself.

8. Submitting the form will trigger the mform processing for this field, which will check fields, create things in the module etc. Once this has been finally successful the developer must call an mform function to "fix" the info for each file and "move" it into the module file area:

eg $mform->store_local_file('uniqueelementid', $context, $filearename, $itemid, $filepath);

9. Cron jobs in File Storage api should automatically delete any files in the user's tempfile area that are older than 7 days or move them into a trash can in the user's file area (perhaps).

===Case 2: As part of a Moodleform without Javascript===

Steps 1-2 are the same as for the case with Javascript.

3. The add file button is a submit button for the form with a different value. When the add file button is pressed,
* the whole form will be ''submitted'' to the original location (but with a different submit button value)
* moodleforms get_data() will detect this is a "repository save" and can save the full POST info in the current session tagged with the id of the openfile element, together with the URL to return to
* moodleforms get_data() then redirects the user to a new page showing the main picker interface

4. The file picker interface will have to be a completely new and separate interface from the AJAX one. It could be a long hierarchy listing, or reload a lot.

5. Finally, when the user selects a file and submits using the "Select" button to picker.php, it will trigger a method in the plugin that will fetch the file and call the [[Development:File_API|File API]] to store the file using the filearea and context information we already had. While this is happening, the interface can show some sort of progress bar (ideally) or at least a "loading file" image/sign/message.

6. After this, picker.php will redirect/continue back to the original form page. The form can be constructed as usual, however, when the form is rendered using display() method moodleforms should now look for relevant saved content in the session and use that to override any content in the form (and then delete the saved info in the session).

Steps 8-9 are the same as for the case with Javascript.

===Case 3: As part of a HTML editor===

The key thing here is a move away from storing any absolute URLs to files in our HTML texts. Instead we'll store relative names.

1. The moodleform for a textarea (HTML editor) will require a path to the filearea associated with this HTML. eg '''wwwroot/pluginfile.php/13/content/0/'''. This would have to be the user_draft area if the filearea doesn't exist yet eg '''wwwroot/draftfile.php/userid/tempfile/uniquelementid'''

2. All textarea content will also need to have str_replace done on it to replace @@pluginfile@@/somefilenames.jpg in the content to use this path so that it comes up right in the editor. (Note this also needs to be done on every format_text command too when showing this text.)

3. The path parameter also needs to be added to the editor configuration in the current page.

4. Editor plugins can be modified to look for these variables in the editor configuration.

5. When adding an image or other media element, the same AJAX repository picker will show up as a popup div to allow people to pick from any repository and choose files to download. The repository picker is responsible for downloading the file in real-time, storing it as a user temporary file if the filearea doesn't already exist, prefixing the supplied path to the filename and returning a URL back to the dialog text input before closing.

6. On submission, and after the HTML is stored, we might now have a new permanent filearea, so we'll need to update any associated temporary files to make sure they have the proper file area information.

==Repository plugins==

Each repository plugin is required to contain the following elements:

===class repository()===

This class implements the interface to a particular repository, for browsing, selecting and updating files. The base class (repository) is defined in /repository/lib.php, while each repository defines an inherited class (eg repository_alfresco) in /repository/repositoryname/repository.class.php

Repositories can redefine any of these methods as required (and in some instances, MUST redefine them):

====__construct($repositoryid, $contextid, $options=array(), $readonly)====

'''MUST''' redefine

Accept necessary parameters, and do initialization of repository.

====get_file($url, $file = '')====

Given a URL, download a file from there, save the file in a temporary directory.

====get_link($info)====
Get the url of external resource

====get_listing($path='/', $page='''''''')====

Given a path, and perhaps a search, get a listing of files. In the case of AJAX file picker, this function should return json format Javascript array.

====search($keyword)====
Search repository by given keyword, it will return an array of the same format of get_listing

====print_login()====

Show the login screen, if required. In the case of AJAX file picker, this function should return json format array which defined the login form.

====print_search====

Print the search form, it will return a json string

====get_meta()====
Return information for creating ajax request, it is private function, you don't need to rewrite it.

====create()====
Create an instance

====delete()====
Delete this instance from `repository` table

====hide()====
Hide a repository instance from file picker list

====set_option()====
set options in data1-data5 fields, can be overrided

====get_option()====
get option list or a specific option from database

====get_type_option_names====
If this plugin needs admin settings, please refine this function to return option names.

====type_config_form====
If get_type_option_names return non empty array, this function '''MUST''' redefine, it will help to build the setting form.

====get_instance_option_names====
If plugin instance needs settings, this function will return instance option names.

====instance_config_form====
If get_instance_option_names return non empty array, this function '''MUST''' redefine, it will help to build the instance setting form.

====supported_filetypes====
What file types are supported by this repository plugin, it will return an array, the file type name is defined in a [http://freemind.sourceforge.net/wiki/index.php/Main_Page freemind] file in lib/file/file_types.mm

====supported_returntypes====
The repository plugin could support external link or copying files to moodle. If the plugin support file link only, developer should override this function to return FILE_EXTERNAL, if plugin support copying file only, it should return FILE_INTERNAL, by default, plugin supports both.

====filter====
Filter file listing to exclude specific file types

===icon.png===

A logo that represents the repository. Ideally square but we should handle all sizes.

==See also==

* [[Development:Repository Administration Specification]]
* [[Development:Repository Interface for Moodle/Course/User]]
* [[Development:Repository plugins]]
* [[Development:Repository File Picker]]
* [[Development:File API]]
* [[Development:Portfolio API]]
* MDL-13766 and MDL-16543 Repository API Meta issues

[[Category:Repositories]]

[[ja:開発:リポジトリAPI]]

Repository plugins

2010-04-19T07:25:12Z

Dongsheng:

A guide for developers on how to create a repository plugin.

== Introduction ==
===Prerequisites===
Before starting coding, it is necessary to know how to use repository administration pages and how to use the file picker.

There is a template attached to MDL-16543 which might be useful to help get you started.

===First steps===
# Create a folder for your plugin in ''moodle/repository/'' e.g. ''moodle/repository/myplugin''
# Create the following files and add them to the plugin folder:
#* ''repository.class.php''
#* ''icon.png'' (the icon displayed in the file picker)
#* "version.php"
# Create the language file ''repository_myplugin.php'' and add it to the plugin folder, keeping the following folder structure:
#*''moodle/repository/myplugin/lang/en_utf8/repository_myplugin.php'' or ''moodle/lang/en_utf8/repository_myplugin.php''
# Create access.php and upgrade scripts

===Overview===

The 3 different parts to write
# Administration - You can customise the way administrators and users can configure their repositories.
# File picker integration - The core of your plugin, it will manage communication between Moodle and the repository service, and also the file picker display.
# I18n - Internationalization should be done at the same time as you're writing the other parts.

==Administration APIs==

As an example, let's create a Flickr plugin for accessing a public flickr account. The plugin will be called "Flickr Public".

Firstly the skeleton:

<code php>
<?php
/**
* repository_flickr_public class
* Moodle user can access public flickr account
*
* @license http://www.gnu.org/copyleft/gpl.html GNU Public License
*/
class repository_flickr_public extends repository {
}
?>
</code>

Then consider the question "What does my plugin do?"

In the Moodle file picker, we want to display some flickr public repositories directly linked to a flickr public account. For example ''My Public Flickr Pictures'', and also ''My Friend's Flickr Pictures''. When the user clicks on one of these repositories, the public pictures are displayed in the file picker.

In order to access to a flickr public account, the plugin needs to know the email address of the Flickr public account owner. So the administrator will need to set an email address for every repository. Let's add an "email address" setting to every repository.

<code php>
//We tell the API that the repositories have specific settings: "email address"
public static function get_instance_option_names() {
return array('email_address');
}

//We add an "email address" text box to the create/edit repository instance Moodle form
public function instance_config_form(&$mform) {
$mform->addElement('text', 'email_address', get_string('emailaddress', 'repository_flickr_public'));
$mform->addRule('email_address', get_string('required'), 'required', null, 'client');
}
</code>

So at this moment all our Flickr Public Repositories will have a specific email address. However this is not enough. In order to communicate with Flickr, Moodle needs to know a Flickr API key (http://www.flickr.com/services/api/). This API key is the same for any repository. We could add it with the email address setting but the administrator would have to enter the same API key for every repository. Hopefully the administrator can add settings to the plugin level, impacting all repositories. The code is similar the repository instance settings:
<code php>
//We tell the API that the repositories have general settings: "api_key"
public static function get_type_option_names() {
return array('api_key');
}

//We add an "api key" text box to the create/edit repository plugin Moodle form (also called a Repository type Moodle form)
public function type_config_form(&$mform) {
//the following line is needed in order to retrieve the API key value from the database when Moodle displays the edit form
$api_key = get_config('flickr_public', 'api_key');
$mform->addElement('text', 'api_key', get_string('apikey', 'repository_flickr_public'),
array('value'=>$api_key,'size' => '40'));
$mform->addRule('api_key', get_string('required'), 'required', null, 'client');
}
</code>

Have we finished yet?

Yes! We have created everything necessary for the administration pages. But let's go further. It would be good if the user can enter any "Flickr public account email address" in the file picker. In fact we want to display in the file picker a Flickr Public repository that the Moodle administrator can never delete. Let's add:

<code php>
//this function is only called one time, when the Moodle administrator add the Flickr Public Plugin into the Moodle site.
public static function plugin_init() {
//here we create a default repository instance. The last parameter is 1 in order to set the instance as readonly.
repository_static_function('flickr_public','create', 'flickr_public', 0, get_system_context(),
array('name' => 'default instance','email_address' => null),1);
}
</code>

That's all - the administration part of our Flickr Public plugin is done. For your information, Box.net, Flickr, and Flickr Public all have similar administration APIs.

===Functions===
All of the following functions are optional. If they're not implemented, your plugin will not have manual settings and will have only one instance displayed in the File Picker (The repository API creates this unique instance when the administrator add the plugin).

==== get_instance_option_names====
''This function must be declared static'' 
Return an array of strings. These strings are setting names. These settings are specific to an instance.
If the function returns an empty array, the API will consider that the plugin displays only one repository in the file picker.
Parent function returns an empty array.

====instance_config_form(&$mform)====
This is for modifying the Moodle form displaying the settings specific to an instance.

For example, to add a required text box called email_address:
<code php>
$mform->addElement('text', 'email_address', get_string('emailaddress', 'repository_flickr_public'));
$mform->addRule('email_address', $strrequired, 'required', null, 'client');
</code>

''Note: ''mform'' has by default a name text box (cannot be removed).''

Parent function does nothing.

====get_type_option_names====
''This function must be declared static'' 
Return an array of string. These strings are setting names. These settings are shared by all instances.
Parent function return an empty array.

====type_config_form(&$mform)====
This is for modifying the Moodle form displaying the plugin settings.
Similar to ''instance_config_form(&$mform)''

====plugin_init()====
''This function must be declared static'' 
This function is called when the administrator adds the plugin. So unless the administrator deletes the plugin and re-adds it, it should be called only once.
Parent function does nothing.

==File picker APIs==
=== Quick Start ===
'''To be completed''' 
First of all, the File Picker using intensively Ajax you will need a easy way to debug. Install FirePHP (MDL-16371) and make it works. It will save you a lot of time. (You might give the [http://moodle.org/mod/forum/discuss.php?d=119961 FirePHP plugin for Moodle] a try, it's still work in progress, though.)

Your first question when you write your plugin specification is 'Does the user need to log-in'? 
.....

For most of plugins, you need to establish a connection with the remote repository. This connection can be done into the get_listing(), constructor() function... 
.....

You wanna display a list of files once the user is logged 
.... get_listing() .....

You wanna retrieve the file that the user selected 
....

Optional question that you should ask yourself is 'Does the user can execute a search' 
.... search() ....

===Functions you *MUST* override===
====__construct====
You may initialize your plugin here, such as:
# Get options from database
# Get user name and password from HTTP POST

====get_listing($path="", $page="")====
This function will return a list of files, the list must be a array like this:
<code php>
$list = array(
//this will be used to build navigation bar
'path'=>array(array('name'=>'root','path'=>'/'), array('name'=>'subfolder', 'path'=>'/subfolder')),
'manage'=>'http://webmgr.moodle.com',
'list'=> array(
array('title'=>'filename1', 'date'=>'01/01/2009', 'size'=>'10MB', 'source'=>'http://www.moodle.com/dl.rar'),
array('title'=>'folder', 'date'=>'01/01/2009', 'size'=>'0', 'children'=>array())
)
);
</code>
'''The full specification of list element:'''
<code php>
array(
// iframe
'iframe' => (string) the url of the iframe, once this option is set, the right panel in file picker will display a iframe instead tree view or thumbnail view, in this mode, plugin developers could design the layout of repository freely, there is a function named repository_downoload_btn, it will display a download button which can help to move files to moodle file system.
// Used to build navegation bar, so you need to include all parents folders
// array(array('name'=>'root','path'=>'/'), array('name'=>'subfolder', 'path'=>'/subfolder'))
'path' => (array) this will be used to build navigation bar
// dynload tells file picker to fetch list dynamically, when user click
// the folder, it will send a ajax request to server side.
// if you are using pagination, 'page' and 'pages' parameters should be used
// and note, you'd better don't use pagination and page at the same time
'page' => (int) which page is this list
'pages' => (pages) how many pages
'dynload' => (bool) use dynamic loading,
// will display a link in file picker
'manage' => (string) url of the file manager,
// set to true, the login link will be removed from file picker
'nologin' => (bool) requires login,
// set to true, the search link will be removed from file picker
'nosearch' => (bool) no search link,
// set this option will display a upload form in file picker
// only used in upload plugin currently
'upload' => array( // upload manager
'label' => (string) label of the form element,
'id' => (string) id of the form element
),
// file picker will build a file tree according this
// list
'list' => array(
array( // file
'title' => (string) file name,
'shorttitle' => (string) optional, if you prefer to display a short title
'date' => (string) file last modification time, usually userdate(...),
'size' => (int) file size,
'thumbnail' => (string) url to thumbnail for the file,
'thumbnail_width' => (int) the width of the thumbnail image,
'source' => plugin-dependent unique path to the file (id, url, path, etc.),
'url'=> the accessible url of file
),
array( // folder - same as file, but no 'source'.
'title' => (string) folder name,
'shorttitle' => (string) optional, if you prefer to display a short title
'path' => (string) path to this folder
'date' => (string) folder last modification time, usually userdate(...),
'size' => 0,
'thumbnail' => (string) url to thumbnail for the folder,
'children' => array( // an empty folder needs to have 'children' defined, but empty.
// content (files and folders)
)
),
)
)
</code>
Dynamically loading
Some repositories contain many files which cannot load in one time, in this case, we need dynamically loading to fetch them step by step, files in subfolder won't be listed until user click the folder in file picker treeview.

As a plug-in developer, if you set dynload flag as '''true''', you should return files and folders (set children as a null array) in current path instead of building the whole file tree.

Example of dynamically loading
See [http://cvs.moodle.org/moodle/repository/alfresco/repository.class.php?view=log Alfresco] plug-in

===Functions you can override===
====print_login====
This function will help to print a login form, for the Ajax file picker, this function will return a
PHP array to define this form.
<code php>
public function print_login(){
if ($this->options['ajax']) {
$user_field->label = get_string('username', 'repository_boxnet').': ';
$user_field->id = 'box_username';
$user_field->type = 'text';
$user_field->name = 'boxusername';
$user_field->value = $ret->username;

$passwd_field->label = get_string('password', 'repository_boxnet').': ';
$passwd_field->id = 'box_password';
$passwd_field->type = 'password';
$passwd_field->name = 'boxpassword';

$ret = array();
$ret['login'] = array($user_field, $passwd_field);
// if you are going to rename submit button label, use this option
//$ret['login_btn_label'] = get_string('submit_btn_label');
// if you are going to display a search form instead of login form
// set this option to true
//$ret['login_search_form'] = true;
return $ret;
}
}
</code>
This will help to generate a form by file picker which contains user name and password input elements.

If your plugin don't require logging in, you don't need to override it, it will call get_listing to list files automatically by default.
====check_login====
This function will return a boolean value to tell Moodle whether the user has logged in.
By default, this function will return true.
====logout====
When a user clicks the logout button in file picker, this function will be called. You may clean up the session or disconnect the connection with remote server here.
====global_search====
Moodle Repository API supports global search, this function will return a boolean value to tell Moodle if this plugin is ready to search. By default, it will return false - you need to override it to enable global search.
====print_search====
When a user clicks the search button on file picker, this function will be called to return a search form. By default, it will create a form with single search bar - you can override it to create a advanced search form.
====search====
This function will do the searching job. You can obtain the POST parameters from the from the form you created in print_search function
This function will return a file list exactly like the one from get_listing.
====get_file====
When a user clicks the "Get" button to transfer the file, this function will be called. Basically, it will download a file to Moodle - you can override it to modify the file then move it to a better location.
====get_name====
This function will return the name of the repository instance.

== I18n - Internationalization ==
These following strings are required in ''moodle/repository/myplugin/lang/en_utf8/repository_myplugin.php'' or ''moodle/lang/en_utf8/repository_myplugin.php'':

<code php>
$string['configplugin'] = 'Flickr Public configuration';
$string['repositorydesc'] = 'A Flickr public repository';
$string['repositoryname'] = 'Flickr Public';
</code>

== Standard repository plugins ==
This is the functional specification list of the officially supported repository plugins.
For each plugins, the two mains part we are interested in are:
* How do I administrate the plugin? See [[Development:Repository_Administration_Specification| Repository Administration Specification - UC001-3]]
* How do I set up an account for this repository? See [[Development:Repository_Interface_for_Moodle/Course/User| Repository Interface for Moodle/Course/User]]

=== Functional specifications ===
*[[Development:Box.net Repository Plugin|Box.net Repository Plugin]]
*[[Development:Flickr Repository Plugin|Flickr Repository Plugin]]
*[[Development:Moodle Repository Plugin|Remote Moodle Repository Plugin]]

==See also==

*[[Development:Repository API| Repository API]]
*[[Development:Repository_Interface_for_Moodle/Course/User| Repository Interface for Moodle/Course/User]]
*[[QA:Use Case Number Attribution| Use Case Number Attribution]]
* MDL-16543 - A list of officially supported repository plugins
* MDL-16543 - Template plugin for developers
[[Category:Repositories]]

Comments 2.0

2010-03-15T07:49:00Z

Dongsheng:

==Objectives==

The goals of comments 2.0:

* Manage comments centrally
* Use a consistent approach for all comments throughout Moodle
* Easily integrate comments 2.0 with existing modules
* Works no matter Javascript is enabled or not

==Overview==

The comments 2.0 provides APIs to:
# Add comments
# Manage comments
# Delete comments

And provides a fancy ajax interface to add/delete comments without loading a new page.

==Comments database table==

{| class="nicetable"
|-
! Field
! Type
! Default
! Info
|-
| id
| int(10)
| auto-incrementing
| The unique ID for this comment.
|-
| userid
| int(10)
|
| who wrote this comment
|-
| contextid
| int(10)
|
| The context id defined in context table - identifies the instance of plugin owning the comment.
|-
| itemid
| int(10)
|
| Some plugin specific item id (eg. forum post, blog entry or assignment submission)
|-
| commentarea
| int(10)
|
| for example, in user profile, you can comment user's description or interests, but they share the same itemid(==userid), we need comment_area to separate them
|-
| timecreated
| int(10)
|
|
|-
| timemodified
| int(10)
|
|
|-
| content
| text
|
| content of comment
|}

==Use Comments API==

===Add an option to format_text function===

Using this format_text function will add a comment icon automatically at the end of the text:

For example, using the following code in the forum module will add a comment icon to every post:

<code php>
$to = new stdclass;
$cmt->contextid = $modcontext->id;
$cmt->area = 'format_post';
$cmt->itemid = $post->id;
$options->comments = $cmt;
echo format_text($post->message, $post->messageformat, $options, $course->id)."<hr />";
</code>

===Use comment class===
To use Comments API elsewhere, using following code:
<code php>
$options->area = 'database_entry';
$options->context = $context;
$options->itemid = $record->id;
$options->showcount = true;
$comment = new comment($options);
$comment->output(false);
</code>

==Comments API overview==

Generally speaking, only two functions you need to know to get comments 2.0 worked:
# Use comment::init to initialize comments 2.0
# Use $comment->output to display comments

The comment class has been implemented in comment/lib.php.
===class comment()===
====__construct($contextid, $comment_area, $itemid))====
Initialize class members

====init()====
It is a static function used to initialize comments, setting up languages, which must be called before html head printed

====output($return = false)====
Will print the html snippet for commenting interface, if set $return as true, it will return html string instead of printing out.

====print_comments($params = array())====
Used by non-javascript comment interface, will print a list of comments.

====add($content)====
Public instance funciton, add a comment to database, used in comment/comment_ajax.php

====count()====
Counting the number of comments

====delete($id)====
Delete a comment from database, used in comment/comment_ajax.php

====delete_comments====
Delete all comments in a specific contexts (like all comments belonging to a forum post)

==Javascript API==
Comments 2.0 implemented a YUI3 module M.core_comment to deal with the communication between browsers and moodle.
It can be found in comment/comment.js

Call M.core_comment.init will create an instance of CommentHelper class. You don't need to make any calls to this instance, it simply works out of box.

== Moodle modules callback ==
Comments API allows modules/blocks/blog to how comments display.

===Permission control===
Modules can implement a function named '''modname_comment_permissions''' to control post and view permission.

Blocks need to overwrite '''comment_permissions''' function of block_base.

Blog need to implement '''blog_comment_permissions''' function.

This function will return an array: array('post'=>true, 'view'=>true)

=== Check new added comment ===
The callback function allows you to change the comment content before inserting into database or reject this comment.

Modules can implement a function named '''modname_comment_add'''.

Blocks need to overwrite '''comment_add''' function.

Blog need to implement '''blog_comment_add''' function.

=== Filter/format comments ===
This callback allows modules check/format comments when user request to display comments.

Modules can implement a function named '''modname_comment_display'''.

Blocks need to overwrite '''comment_display''' function.

Blog need to implement '''blog_comment_display''' function.

=== Define a comment template ===
Modules can implement a function named '''modname_comment_template''', which allow modules define a comment template.
The template must have 4 embedding variables, ___id___, ___content___, ___time___, ___name___, they will be replaced with html id, comments content, comment time and commenter name

==See also==
* MDL-19118 - Comments 2.0 issue

Användare:Dongsheng Cai

2010-01-24T13:29:14Z

Dongsheng:

I am a Moodle developer working at [http://moodle.com/hq/ Moodle HQ]

My main works with Moodle:

* [[Chats|Chat module]]
* [[Development:Repository_API|Moodle Repository API]]
* [[Development:Comments_2.0|Comments 2.0]]

More:
* [http://www.ohloh.net/accounts/cai Ohloh]
* [http://github.com/dongsheng My Github]
* [http://au.linkedin.com/in/dongshengc Linkedin]
* [http://dongsheng.org My website (in chinese)]

Användare:Dongsheng Cai

2010-01-24T13:25:36Z

Dongsheng:

I am a Moodle developer working at [http://moodle.com/hq/ Moodle HQ]

My main works with Moodle:

* [[Chats|Chat module]]
* [[Development:Repository_API|Moodle Repository API]]
* [[Development:Comments_2.0|Comments 2.0]]

More:
* [http://www.ohloh.net/accounts/cai Ohloh]
* [http://github.com/dongsheng My Github]
* [http://github.com/dongsheng My Github]
* [http://dongsheng.org My website (in chinese)]

blocks/section links

2010-01-18T05:58:44Z

Dongsheng:

This block can help to navigate sections in a course.

Some courses contains a lot sections, it may be hard to find the section you really need. This block will create quick jump links to navigate to sections instantly.

In block setting page, you can determind the 'increase by' value to meet your needs.

Section Links block settings

2010-01-18T05:54:19Z

Dongsheng:

These settings are used to make section links block more flexable.

There are two 'number of sections' value in the setting page, say numsections1 and numsections2.

If the number of sections in the course is less than either of them, the section links will increase by 1.

If the number of sections in the source is more than both of numsections1 and numsections2, and numsections2 is more thank numssections1, the increase by value will respect numsections2's increase by setting.

If the number of sections in the source is more than numsections1, but less than numsections2, the increase by value will respect numsections1's increase by setting.

Section Links block settings

2010-01-18T05:53:58Z

Dongsheng:

These settings are used to make section links blog more flexable.

There are two 'number of sections' value in the setting page, say numsections1 and numsections2.

If the number of sections in the course is less than either of them, the section links will increase by 1.

If the number of sections in the source is more than both of numsections1 and numsections2, and numsections2 is more thank numssections1, the increase by value will respect numsections2's increase by setting.

If the number of sections in the source is more than numsections1, but less than numsections2, the increase by value will respect numsections1's increase by setting.