MoodleDocs - User contributions [en]

Arguments in favour of PostgreSQL

2009-04-06T21:23:45Z

Shinoda: Link to Mahara's opinion about MySQL vs. Postgres ;)

Martin Langhoff argues '''in favour of PostgreSQL''' (source: [http://moodle.org/mod/forum/discuss.php?d=24831#121862 Moodle over webct and LNLS at Athabasca University?] forum posting)

There are several reasons to go with Postgres, I'll try to make a brief outline. We run a variety of RDBMSs at Catalyst, and have a lot of in-house experience with them: Oracle, Postgres, MySQL and Progress, plus a few others. We also have experience with replicated databases, clustering and other tricks -- which we use for the backend of the .nz root domain servers as well as a few other mission-critical systems.

On the performance side, Postgres requires a bit more up-front configuration than MySQL. A well tuned Postgres is pretty close on SELECT performance to MySQL with small databases. With large tables MySQL has some bad performance problems, and Postgres performs much better.

Write performance is also an issue with MySQL -- with a lot of traffic, it has serious problems with concurrent writes. Under heavy load, Postgres performs much better.

But to tell you the truth, the real reason for choosing Postgres is reliability. We maintain a lot of databases, and Postgres is rock-solid reliable and has a focus on ACID-correctness: when it returns from a commit, the data is safely on disk and won't be lost -- barring actual disk problems, which we offset using RAID-1.

No matter how hard we try, MySQL databases with a lot of usage have recurring index corruption issues. If you look at the startup scripts for MySQL on most Linux distributions, they check for data corruption on every startup -- this is to mask the fact that it is a frequent occurrence.

And while this is passable with small installations where the data isn't mission critical, you have to consider how much you can trust such approch. And with large datasets, runing isamchk/myisamchk can take hours -- we cannot afford that.

The clustering solution for MySQL is being touted a lot, and I think it is a red herring. My main concern about is that it writes "asynchronously" -- that is, there is no guarantee that your data is on-disk safely. It'll get to the disk sometime. It'll get to the slaves... sometime. Hmmm.

Given that the MySQL cluster uses async writes, splitting read/writes between the master and the slaves breaks down in cases where we write some data, and read it back in immediately (or soon after). And this does happen in quite a few places.

And you also have to consider the performance boost of using async writes: if you tell a standalone Postgres or MySQL to use async writes, it'll scale much better (should be able to handle up to 3-4 times more simultaneous writes). Once you do that, the performance advantage of the MySQL cluster mostly vanishes. It still has semi-hot takeover in case the master goes down, but Postgres can do that using Slony, and with better guarantees of consistency of the data in the slave.

In a nutshell, MySQL isn't normally very solid when it comes to ensuring my data is safely stored on-the-disk, even if it theoretically guarantees that it's been saved. And MySQL Cluster says up-front that there isn't a guarantee any more. Riiiiiight wink

Michael is talking about having UPSs. We have a car-sized UPS and a container-sized on-site generator that auto-starts. And yet, I wouldn't depend on that for my DB consistency on a large Installation. So many things other than power can (and do) go amiss. If a process has a problem storing the data, the right thing is to tell that back to the user. With async writes, you end up with a queue of data that hasn't been stored yet, but you already told the user it was.

That's not what a database is supposed to do.

I am currently exploring some techniques similar to those being used in livejournal and slashdot. We should be able to increase Moodle scalability by cutting down on DB load by about 50%. This is happening slowly in the gaps between more urgent projects. Feel free to ping Richard or me if you're interested in that track.

===See Also===
* [https://docs.moodle.org/en/Step-by-step_Install_Guide_for_Ubuntu#Install_Postgresql_.28skip_MySQL.29 Installing Postgres on Ubuntu(Debian)]
* [http://mahara.org/interaction/forum/topic.php?id=302 MySQL vs. Postgres in Mahara] (Mahara is a webapp built in a very similar manner to Moodle, all the arguments there apply to Moodle too).

[[Category:Administrator]]
[[Category:Performance]]

[[pl:Argumenty za PostgreSQL]]
[[ja:PostgreSQLを使う理由]]

error/mnet/hostnotconfiguredforsso

2008-09-16T06:08:06Z

Shinoda: Initial edit

This means that you have clicked on a link in the 'Network Servers' block to go to a remote host, but that your administrator has not ticked the appropriate boxes when setting up the network connection to that host.

In particular, the administrator has ticked the box to provide the 'SSO Identity Provider' service, but has not ticked the required dependency box to subscribe to the remote host's 'Service Provider' service.

This screenshot shows the issue:

[[Image:Mnet-misconfigured-sso-sp-setting.png]]

Administrators: be very careful to read this page. When configuring SSO, you always need to check at least TWO boxes.

File:Mnet-misconfigured-sso-sp-setting.png

2008-09-16T06:05:20Z

Shinoda: A screenshot of the MNET peer "services" tab in Moodle, showing incorrectly configured SSO.

A screenshot of the MNET peer "services" tab in Moodle, showing incorrectly configured SSO.

Development:Portfolio API

2008-07-22T20:06:08Z

Shinoda: /* Duplication of Cata */

This page describes the specification for a future feature, currently being worked on for [[Roadmap|Moodle 2.0]]. This spec is STILL UNDER CONSTRUCTION.

==Overview==

The Portfolio API is a core set of interfaces that all Moodle code will/should use so that we can easily publish files to all kinds of external document repository systems.

It's important to remember that portfolios are generally treated as WRITE-ONLY. All we are doing in Moodle is grabbing stuff and pushing it out to somewhere. Management of the files and further combining/reflecting is done through the native interface provided by the portfolio system. Reading of files from a repository is handled by the [[Development:Repository API|Repository API]].

A typical user story:

# When portfolios are enabled, every page or major piece of content in Moodle has a little "Save" button beside it.
# User clicks one of these buttons
# User is able to choose from a list of configured portfolios (this step will be skipped if there's only one).
# User may be asked to define the format of the captured content (eg pdf, IMS LD, HTML, XML ...)
# User may be asked to define some metadata to go with the captured content (some will be generated automatically).
# The content and metadata is COPIED to the external portfolio system
# User has an option to "Return to the page you left" or "Visit their portfolio".

Note this will be just as useful for teachers as for students.

The formatting possibilities will vary depending on the context of the button and the type of external portfolios. So for example, the "Save" button on the course page would allow the user to capture the whole course in IMS LD or Moodle backup format, which you would not have on a forum page.

==Architecture==

Here is how it will work:

===Plugins and libraries===

There will be two separate types of plugins

# Portfolio (eg Mahara/Elgg/OSP/Facebook/Download) - this will be portfolio/type/xxx
# Transport (eg mnet/http/scp/cp/dav etc) - these will be reused across different portfolio plugins

Then there will be different formats that plugins will support (and the part of moodle exporting content must support as well), eg IMS, moodle native, mahara native, pdf, enrypted pdf. These will have good libraries supporting them.

The reason for this is that I can see for abstracting the transport layer to its own plugin type is that it's pretty likely that the same external system might talk both portfolio and repository.

===Admin===

It is important to be allowed to have multiple instances of (some) plugins. The workflow for adding a new one is:

*Admin navigates to portfolio config
*Selects from the list of available portfolio plugins, and clicks 'add a new external portfolio' (some may be disabled if there is an instance already and the plugin doesn't support multiple instances)
*Configure the plugin - select which transport and content types to use if there are multiple supported and installed, urls, authentication keys, etc.
*Set permissions (maybe) - handled by roles.

This is not necessary for every type of portfolio, because many will just require the user to authenticate directly and if we do ever want to retain settings for each user we just use user preferences.

===Exporting===

*User is viewing a page that calls portfolio_add_button(). This checks to see if there are any configured portfolio plugin instances, and also (maybe) any permissions related to portfolios, and what the user's portfolio settings are, and then displays either a single 'add to portfolio' button, or a drop down menu of the available systems with the add button.
*When this button is pressed, the user is redirected to portfolio/add.php, with some post data containing the responsible area (activity module or something like course or blog) callback file and function.
*On this page, the user is presented with a form to enter metadata about the item, and configure any options. At this point if there are multiple formats available for export (based on the intersection of what the plugin and module support), the user can select which format they want. The plugin and module can both export mform elements for this page. The user can at this point also select to send the data and wait (with a warning it might take awhile), or queue it for processing if it's larger.
*When the user has submitted the form, they are displayed a summary of what they're about to export, with 'confirm' and 'edit' buttons. Edit just relaunches the form, and confirm goes to the next step.
*At this point, the portfolio plugin (or transport plugin) might need to take control for a step. For example, facebook or flickr might require the user to log in for the first time and confirm moodle is allowed to access their API
*When the user has confirmed their summary, a 'portfolio_send' event will be triggered. At this point, one of two things happen.
# If the user has elected to wait, the 'instant' event is fired, and when the caller gets control again, it displays the status to the user.
# If the user has elected to queue, the delayed event is fired and the user is notified.
*The user is given the option to continue to their portfolio, or return to where they were
*
*When the event is handled (either through the cron or instant event), the following happens:
*The event handler is invoked. This is almost certainly going to be a function in lib/portfoliolib.php rather than any handler in the portfolio plugins. The event handler in turn calls the original callback that was passed to portfolio/add.php (module//lib.php or course/lib.php or something), which prepares the data in the format the user selected and returns control to the event handler.
*At this point we have all the metadata we need, and we have the content to send, so it's time to start transport negotiation, which happens in stages. Note that some plugins might not implement all stages, and 3 and 4 might be interchangeable in order, depending on the external system.
#request
#authentication
#content
#metadata (some control is passed to the portfolio plugin for packaging - either to just write out an xml file and zip up the whole package, or send a series of requests)
#completion
*When this is complete, we return control to the event handler (which, if it's an 'instant' one, will return true to the caller, which will be the ajax request)

===Storage===

Obviously during this process, state is going to be lost between webserver requests and also between user input and event handling. Some data will be stored in the user's session (the result of the metadata form, for example) and some in temporary files on the file system. These will be stored in dataroot/temp/portfolio/$userid-$timestamp/

===Access/Permissions===
* Portfolio plugin must be allocatable per context (site/course/group etc)
* How can we assume all users will have an account on the remote system? We could try and silently authenticate them (or at least see if it's possible to) in the background at the first call to portfolio_add_button (and then cache the result in the session)
* Check MNet policy - it assumes everyone with the role can have an account (assuming they_sso_in or whatever it's called is on) - this doesn't scale though, other transport mechanisms and or plugin types might not follow this assumption. I think this really must be defined by the portfolio plugin only, not the transport plugin.

===Event API===

It is probably worth using the event api to handle the sending of data, mostly just because it provides a handy way of detached processing. However, any portfolio_send event will be 'owned' by particular "instances" of plugins - and each plugin that subscribes to portfolio_send event (all of them by definition) will have to check if the event data belongs to any of their instances, which is potentially quite messy.

==Technical==

===Abstract Portfolio Baseclass: portfolio_plugin_base===

Mixes providing some basic functionality by means of its own functions, with a number of abstract functions plugins must implement, and with some functions that plugins can also optionally override.

See also: [[Development:Writing_a_Portfolio_Plugin]] for a full list of all methods you must/can/shouldn't override, as well as associated instructions for what else you need to do to create a new portfolio plugin

===Abstract Caller Baseclass : portfolio_caller_base===

Whenever somewhere in Moodle wants an 'add to portfolio' button, they must subclass this.

See also: [[Development:Adding_a_Portfolio_Button_to_a_page]] for a full list of all methods you must/can/shouldn't override as well as the associated instructions for how to call portfolio_add_button.

===Database Tables===

The actual information about plugins that are installed is just stored in mdl_config.

Additionally, as we're configuring instances of plugins, rather than just one config set per plugin, we're not using mdl_config_plugin, but instead our own set of tables:

'''portfolio_instance:'''

{| border="1" cellpadding="2" cellspacing="0"
|-
|'''Field'''
|'''Datatype'''
|'''Comment'''
|-
|id
|integer
|sequence
|-
|plugin
|varchar(50)
|name of plugin (should match directory in portfolio/type)
|-
|name
|varchar(255)
|name of this plugin instance
|-
|visible
|smallint
|0 or 1
|}

'''portfolio_instance_config:'''

{| border="1" cellpadding="2" cellspacing="0"
|-
|'''Field'''
|'''Datatype'''
|'''Comment'''
|-
|id
|integer
|sequence
|-
|instance
|integer
|(pseudo)fk to portfolio_instance
|-
|name
|varchar(255)
|config name
|-
|value
|text
|config value
|}

'''portfolio_instance_user:'''

{| border="1" cellpadding="2" cellspacing="0"
|-
|'''Field'''
|'''Datatype'''
|'''Comment'''
|-
|id
|integer
|sequence
|-
|instance
|integer
|(pseudo)fk to portfolio_instance
|-
|userid
|integer
|(pseudo)fk to mdl_user
|-
|name
|varchar(255)
|config name
|-
|value
|text
|config value
|}

All plugins can also implement their own database tables as needed, by creating a db/install.xml and db/upgrade.php inside portfolio/type/xxx/ (See [[Development:Writing_a_Portfolio_Plugin]]) for more information.

===Portfolio Plugins===

#[[Development:Mahara_Portfolio_Plugin|mahara]] (will be done for the initial implementation)
#download (should be done for the initial implementation)

transport types and formats should be able to be found in a shared location for multiple plugins of both portfolio and repository type to use, but also might be specific to one type of plugin which means that moodle should support looking in multiple locations for these plugins. (eg mahara native format will be in the mahara portfolio plugin, but pdf format will be in a shared library)

===Possible Transport Types===

# mnet (will be done for the initial implementation as part of the Mahara Portfolio Plugin)
# download (will be done for the initial implementation as part of the Download Portfolio Plugin)
# http
# filesystem (could be local/nfs/samba whatever) (cp)
# ssh based (eg scp - should find and re-use the elgg block code as it deals with using ssh keys nicely)
# webdav
# open social? (http://code.google.com/apis/opensocial/)

===Possible Export Formats===

(Note that we don't necessarily want more than one of these for the initial implementation)

# html
# pdf
# encrypted pdf
# ims?
# leap/piop? (http://wiki.cetis.ac.uk/LEAP_2.0) -- looking increasingly possible Mahara will speak this, so hopefully for the intial implementation
# moodle native?
# mahara native?
# Dublin Core (Enovation implemented this)

===Testing===

Nico to help (see Development Approach for TDD-related approach)

==MNET==

This section has moved to [[Development:MNET_Roadmap]]

==Duplication of Data==

Moodle will keep track of what content it transfers and when. It'll remember the url of the original export location (alphabetisising the url parameters and removing the sessionkey) and a sha1 hash of the data, so that if the user tries to export the same content, Moodle can warn the user (along with a notification of whether it has changed or not).

At this point we can build support into the API for plugins to offer to differentiate between 'replace' and 'add', but won't implement it for any we write for the initial implementation.

==Assumptions==

* Using Moodle's built in Event API

==Outstanding questions==

*which parts of Moodle will have this button to start with (in order of necessity)
*Dependance of transport plugins - eg filesystem might depend on http for sending request/finished pings

==Development Approach==
* create two base classes
* create mahara portfolio plugin, relying on mnet
* create portfolio/add.php and portfolio/lib.php
* start adding calls to the portfolio_add_button function to various places in moodle, with their callbacks.
* create a dummy listener in mahara until the mahara side is specified

After a conversation with Nico about testing, we decided the most sensible ordering to start with would be:

# Write portfolio/add.php
# Write *skeleton functions* to support it in portfolio/lib.php and the class structure
# Write tests for those methods that are necessary
# Implement the functions to make the tests pass
# Keep adding module implementations

==See also==
* [[Development:Repository API]]
* [[Development:File API]]

Development talk:Mahara Portfolio Plugin

2008-07-22T11:41:53Z

Shinoda:

=== Question 1 ===

It occurs to me that maybe Mahara could send back information about where files could be put/blogposts could be stored etc, as part of the reply to the "intent to send" request? In the "happy path", we wouldn't expect this information to change, so maybe it's safe to send back something then? [[User:Nigel McNie|Nigel McNie]] 07:40, 20 July 2008 (CDT)

We'd have to send back information about where to put any possible content though, because at the intent to send stage, we don't know what format it is (eg, it might just be a file but could be a LEAP/PIOP component, which would go into a whole another artefact plugin). we'd essentially have to send back the entire artefact tree. and then even if we did that, at that point Moodle still doesn't know what format the user wants, so we'd still have to add another step._
[[User:Penny_Leach|Penny Leach]]

=== Proposed MNET Changes ===

I think the application2service table is a good idea (no more Mahara "course enrolments"!). But I don't like the idea that the URL field is in this table. Even though it varies by application, it doesn't apply to _every_ service, and therefore is redundant much of the time. Furthermore, if more services are added that need their own custom per-application fields, all of a sudden this table is getting very big with a lot of poorly related fields.

A different model that doesn't suffer the problem is this:

==== application2service ====

{| border="1" cellpadding="2" cellspacing="0"
|-
|'''Field'''
|'''Datatype'''
|'''Comment'''
|-
|id
|integer
|sequence
|-
|applicationid
|integer
|fk to mnet_application
|-
|serviceid
|integer
|fk to mnet_service
|}

==== application2service_sso ====
{| border="1" cellpadding="2" cellspacing="0"
|-
|'''Field'''
|'''Datatype'''
|'''Comment'''
|-
|id
|integer
|sequence
|-
|a2sid
|integer
|fk to application2service(id)
|-
|url
|char(255)
|
|}

[[User:Nigel McNie|Nigel McNie]] 06:41, 22 July 2008 (CDT)

Development talk:Mahara Portfolio Plugin

2008-07-22T11:39:16Z

Shinoda: Note about application2service table

Development talk:Mahara Portfolio Plugin

2008-07-20T12:40:20Z

Shinoda: /* Question 1 */

Development talk:Mahara Portfolio Plugin

2008-07-20T12:40:00Z

Shinoda: New page: === Question 1 === It occurs to me that maybe Mahara could send back information about where files could be put/blogposts could be stored etc, as part of the reply to the "intent to send"...

Development talk:Repository API

2008-06-17T12:08:00Z

Shinoda:

(Ideas will be deleted from the comments section as they are resolved or merged into the main spec)

===Missing concept of trusted files===
Files are not created equal, some of them are to be trusted, some can not be trusted at all. Web browsers trust everything received from the server, files from server may access cookie information and thus scripting technologies may allow them to do anything user can do. We do have to trust our teachers because they are supposed to create the learning content, but we definitely can not trust all students.

Imagine if students were allowed to upload arbitrary files to server, like html file loaded with javascript and the server would happily serve them to all Moodle users. Our solution is to use html cleaning filters for submitted texts and force downloads of student uploaded files. To do this we must know if we trust the files or not. Unfortunately the forced downloads of student uploaded files and cleaning of html texts does not solve all problems, because bugs in browsers and especially browser plug-ins may sometimes be used to work around our protections.

The best solution would be to use separate web addresses for trusted and not trusted files (two wwwroots in config.php), not all sites may afford two different addresses but we should be imo prepared for this. [[User:Skodak|Skodak]] 16:42, 28 February 2008 (CST)

Great idea, yes. In fact couldn't all the files be served via $CFG->fileroot all the time?
[[User:Martin Dougiamas|Martin Dougiamas]] 07:08, 29 February 2008 (CST)

userid field could be used for this, but separate flag might be better in order to allow teachers to upload untrusted files (teacher uploads assignment submission for the student).

===Relative file links===
Flash, Java and SCORM require relative links and directory hierarchy in general - we must support it. Some SCORM packages load hundreds of files per page which means the file serving must be very fast with minimum of db access.

Reading the proposal above it seems the API is about serving of isolated files referenced by repository ids. HTML requires to use relative or absolute locators with file names, we can not use repository ids directly in relative links. In case of scorm we have absolute path to base of SCORM package of given activity and SCORM files use relative links inside the package.
Solution could be to store relative paths directly in filename field ex:directory1/directory2/filename.ext.

Yes I agree, we definitely need to support (virtual) directories and slasharguments.
We could just match the file argument to a path in the db. Perhaps add the fileid
to the argument path as a primary key: fileid/directory1/directory2/filename.ext
[[User:Martin Dougiamas|Martin Dougiamas]] 07:08, 29 February 2008 (CST)

===Virtual directories and files===
Sometimes the content of files is generated on the fly (csv exports, etc.), there are many special files spread through codebase doing nearly the same, it should be imho possible to use the same file API for these.

Another virtual example is assignment submissions and webdav. I would like to see an option to browse the assignment submissions as directory structure, the top directory would be a list of names of users, inside html files with online assignment and uploaded files. This would allow us to implement simple zip&go or webdav based offline grading solutions. The problem here is that the content of this virtual submissions directly needs to be created on the fly based on user references, the proposed repository structure can not be used for this.

Very interesting idea! [[User:Martin Dougiamas|Martin Dougiamas]] 07:08, 29 February 2008 (CST)

===Backup/restore relinking===
We are supporting relinking inside courses only. Till now it was easy to guess if absolute link will work after restore on another server.
There are several types of files:
*course files - relinked during restore, works on any server if from the same course
*module files - not relinked, urls are not permanent, link can not be copypasted (assignments, forum attachments, rss files, etc.)
*user files - not relinked, links work only on original server (blog attachments, personal files, etc.)

I think all this will be simplified in the proposed system because everything is
represented using the same system: a file with an ACL (backup can quickly
determine all the files in one course, probably using one SQL query).
[[User:Martin Dougiamas|Martin Dougiamas]] 07:08, 29 February 2008 (CST)

If we are backing up/restoring on the same server, will copies of a course restore without file duplication? I use this a lot so that I can archive one year's course whilst modifying it for next year. [[User:Matt Gibson|Matt Gibson]] 03:12, 29 April 2008 (CDT)

===Access needed for both file and its instances===
We need two types of access control - first who can create instances (link files), second who can access the instance (download the file).

For the first don't we already have those capabilities? (like mod/forum:createattachment,
moodle/course:managefiles) but they probably could use rationalising. We'll need new
ones per repository, too, of course.
[[User:Martin Dougiamas|Martin Dougiamas]] 07:08, 29 February 2008 (CST)

===Cache lifetime===
There should be a way to specify cache filetime for each instance of file. For example 0 for uploaded assignments, 1 day for resource file. It might be better to allow modules to decide about this, at present it is hardcoded in file.php.

Great idea. [[User:Martin Dougiamas|Martin Dougiamas]] 07:08, 29 February 2008 (CST)

== Hierarchy in tables ? ==

It's possible that I don't undertand a key piece of the concept, but I wonder why there is no reference to any "parent id" in the file or file_instance table ?
In other words, how the hierarchical structure is supposed to be "imported" from repository to Moodle ?
If the hierarchy is reserved to the course context, and not to the repository context, it seems difficult to allow students to access
to a complete directory, for example.

On the other hand, maybe it's only a question for the "local" repository type, and not to the "generic" repository API ?
[[User:Allegre Guillaume|Allegre Guillaume]] 16:43, 5 March 2008 (CST)

[[User:Martin Dougiamas|Martin Dougiamas]] 12:58, 15 March 2008 (CDT): basically I was thinking we just store a full local path for each file instead of hierarchies. It wasn't in the db schema though: I've just added it. Thanks!

As for allowing access to a whole directory, that's something I've not thought about - thanks! I agree we need to support something like that in the interface. Hmm ..

== Editing Repository Files / Version Control ? ==

How do you imagine to handle the "editing file" problem ?
I can see several solutions :
# the simplest way : write access to a file really allows to edit (re-upload) the file, each instance being modified
# the "cheap copy" way : optionally, the modification is applied only to new file_instances (or those for which the teacher forces to). Here you have to handle two (then maybe more) revisions of this file.
This triggers the file revisions (or version control) question.

A related question is about versionned files :
should it depend only upon the repository layer (for example, a plugin could implement a SVN "repository") ?
Or should Moodle be aware of the file "revision number" ?
[[User:Allegre Guillaume|Allegre Guillaume]] 17:00, 5 March 2008 (CST)

[[User:Martin Dougiamas|Martin Dougiamas]] 13:08, 15 March 2008 (CDT): I don't think we should start getting into such things, version and editing is the job of the dedicated external repository system and people should use that interface.

What we do have in Moodle is the file->updates field. This specifies when to get a fresh copy. It would be set when the user has specified they want Moodle to use the "latest version" of the file. And if the user specified a particular version in the repository interface then that is what gets copied (once) and the file->updates field is left as zero.

One scenario would be if someone wants to use version 1 in one course and version 2 in another, but since the version is in the URL to the original file (and thus a different remote path) they would be treated as two separate files in Moodle anyway.

Might be a small problem if they said "latest version, no update" in course 1 and then later on said "latest version, no update" in a second course. I guess that would re-download the latest version (which might have changed) and thus course 1 would have an unexpected update. We could solve this by alerting the user and giving them a choice, I suppose.

== Replacing Moodle's File System ==

The API as specified still uses the standard Moodle file system, which has its limitations while providing a simple file access method. But, shouldn't we also be considering completely (or partially) replacing the Moodle file system with the repository system? To that end, the file interface would be the same to users, but where the files are and how they are accessed would be up to which repository was being used. In this system, the standard Moodle file system would just be one of the available repositories. Then the API could support more robust access controls if available, or very few (as Moodle does now). This could allow for per-directory / per-file privilege granting, common file areas so that courses could access the same copy of a file (rather than copying it into the Moodle file area), etc.

The API could also support multiple repositories and allow choosing a file as a link rather than copying it.

Of course, this would also mean allowing write access to the repository area from Moodle, rather than leaving it as read-only. I know the plan was to do this through the [[Portfolio API]], but that really is limited to a user storage function and not a file management function. I think having an API defined to allow for full file management would be a better solution - even if not supported by all repositories.
[[User:Mike Churchward|Mike Churchward]] 12:54, 6 March 2008 (CST)

[[User:Martin Dougiamas|Martin Dougiamas]] 12:54, 15 March 2008 (CDT) :
Actually, Mike, the standard file system is NOT being retained at all. I've clarified this slightly in the docs. The course-centered structure for files is gone. All files ARE stored on disk but most of the info regarding their location and access is all governed by a table in the database (so the files could just as easily be in a remote database if you wished). Files used in multiple areas within Moodle will never be stored more than once in Moodle.

The idea of a read/write interface was how we started, but it's insanely complex once you try to handle backups (ie how do you make a complete backup suitable for giving to someone else?) and access control (how do you decide access depending on Moodle contexts), and we'll never do it as well as the original repository does it. Why should we duplicate the Hive interface (to use an example) in Moodle when Hive has a perfectly good one already, one that handles all the extra stuff like Copyright controls, workflow and so on?

That said, the current Repository plugin idea is very simple, so that if anyone really wanted to embed management into the "file picker" interface they totally could do it in the plugin.
---

==Windows network drives==
I've added this to the end of the list of repository types to be supported because its possibly the most useful one I can think of. Our school wants to make the transition to moodle, but getting the files on there is the biggest barrier and there is a lot of stuff sitting on our shared and personal folders which is time consuming to transfer. Integration is a big thing that management want to see, particularly the ability to bulk upload files. This may not be a repository as such because it may be that the best way is to copy the file from the shared folder into the repository rather than where it is so it can be moved/deleted accidentally, but easy access is vital in making the process of uploading a file possible. It would also make Moodle a killer app in that it could make our network drives available from home through a secure web interface.

I've linked to Guy Thomas' [http://moodle.org/mod/data/view.php?d=13&rid=991 Windows Share Web Client block] as it is a good start, but sadly only works on Linux. [[User:Matt Gibson|Matt Gibson]] 03:43, 29 April 2008 (CDT)

Fantastic idea, let's call it the SMB plugin - [[User:Martin Dougiamas|Martin Dougiamas]] 21:25, 8 June 2008 (CDT)

==Bulk operations==
On a similar note, Don Hinkelman's new course format provides a great bulk-upload feature whereby a whole folder can be uploaded and added to the course as resources with the names of the files as titles, with just a couple of clicks. I know this is extending the repository idea a little, but to be honest, I think that one of the biggest weaknesses of Moodle's file handling right now is not being able to add an entire folder of files without manually going through each one and laboriously specifying location and title. To make any repository useful, I think three operations should be possible with one or two clicks:
* Add a whole folder/group of files to the repository at once
* The above operation, but additionally, have all of the folder/group added to a course and named automatically, all in one go.
* Find a group of files which are already in the repository and add them to a course all at once, with automatic naming as above.
Not sure if this is best put here or in the Developemt: File_API bit, but here seemed slightly better. [[User:Matt Gibson|Matt Gibson]] 03:43, 29 April 2008 (CDT)

This is probably not related to the file API at all. I'd see it as being a new item on the resource menu (Add multiple resources ...) with some sort of shift-click scenario. nice idea though. Can you file it as a tracker item? [[User:Martin Dougiamas|Martin Dougiamas]] 21:26, 8 June 2008 (CDT)

== Bulk and a new resource type from repository ==

Our school has several campuses and a distance learning unit with well organized and big course resource trees. The repository module could be enormously useful for us.

I have looked at Moodle's IMS repository a bit, and like the way it is possible to put multiple resources into one access point. If the new repository could have some of the same possibilities, it would be marvellous. The drawback with the IMS is that it opens a new window with all the multiple resources. Instead, it would be OK to be able to share a whole lot of resources, or a whole "resource tree".

I also like the bulk function, to be able to parse a folder of say, html-files, and add it to the resource tree.

==Further notes==

* WebDAV --[[User:Helen Foster|Helen Foster]] 17:20, 9 June 2008 (CDT)

== "local repository name" ==

I think users will find the word local to be confusing. For the developer or administrator, local seems to refer to the Moodle server. But for the teacher or student, they will think that local refers to their own local files system. I would suggest just using the domain name for that server (like myMoodleSite.org) and list it as the first entry to avoid this confusion. [[User:Gary Anderson|Gary Anderson]] 02:40, 10 June 2008 (CDT)

== Credentials to third party systems ==

You might want to consider something like oauth - http://oauth.net - to manage credentials of third party sites, rather than asking the user for them. I know I sure wouldn't want to input my credentials for one system into another! [[User:Nigel McNie|Nigel McNie]] 07:08, 17 June 2008 (CDT)

Code syntax highlighting

2006-07-19T12:38:26Z

Shinoda: Server downtime, added section on development

You can color or highlight code snippets within Moodle resources, forum posts etc. To do so you must install the GeSHi (Generic Syntax Highlighter) Filter. This makes the power of GeSHi available in Moodle through the use of a pair of special tags.

== Installing ==

You can download the GeSHi filter from here:

http://geshi.org/downloads/moodle-geshi-filter-0.1.0.zip (note: down as of 2006/07/19 12:34 GMT due to server move, should be complete in a few hours)

To install, unzip that archive into your filter/ directory and then enable it in the admin filter configuration screen.

== Instructions for use ==

Enclose your code in spans like so:

<nowiki>[code lang]your code goes here [/code]
[code lang linenumbers]your code with line numbers [/code]
[code lang highlight=1,2,6-9]your code with lines 1, 2 and 6 to 9 highlighted "extra" [/code]
[code lang linenumbers start=4]start the line numbers at "4" [/code]</nowiki>

=== Supported languages ===

* asm,
* bash,
* cpp,
* [[CSS]]
* lisp
* matlab
* [[HTML]]
* [[PHP]]
* pascal
* sql
* xml

and many others. See the GeSHi homepage for full details.

=== Options ===

See the examples above. This filter is still under development so things may change.

== Demo ==

The filter has recently been installed on Moodle.org and can be seen in use there. For example see this post:

http://moodle.org/mod/forum/discuss.php?d=25413#195644

The GeSHi homepage also has an interactive demo.

http://qbnz.com/highlighter/demo.php

== History ==

This filter used to use <nowiki>...</nowiki> as markers for code. However this changed after conflicts with the HTMLArea editor became apparent.

== Development ==

At this time this filter is under development. Suggestions for new features and bug reports are welcome, please post them in the [http://moodle.org/mod/forum/discuss.php?d=43266 discussion thread].

== See also ==

* [http://moodle.org/mod/forum/discuss.php?d=25413 Forum post introducing the Filter]
* [http://moodle.org/mod/forum/discuss.php?d=43266 Forum thread for progress reports and feedback]
* [http://qbnz.com/highlighter/ GeSHi homepage]

[[Category:Administrator]]
[[Category:Filter]]

Code syntax highlighting

2006-07-18T11:12:53Z

Shinoda: /* Instructions for use */

You can color or highlight code snippets within Moodle resources, forum posts etc. To do so you must install the GeSHi (Generic Syntax Highlighter) Filter. This makes the power of GeSHI available in Moodle through the use of a pair of special tags.

== Installing ==

You can download the GeSHi filter from here:

http://geshi.org/downloads/moodle-geshi-filter-0.1.0.zip

To install, unzip that archive into your filter/ directory and then enable it in the admin filter configuration screen.

== Instructions for use ==

Enclose your code in spans like so:

<nowiki>[code lang]your code goes here [/code]
[code lang linenumbers]your code with line numbers [/code]
[code lang highlight=1,2,6-9]your code with lines 1, 2 and 6 to 9 highlighted "extra" [/code]
[code lang linenumbers start=4]start the line numbers at "4" [/code]</nowiki>

=== Supported languages ===

* asm,
* bash,
* cpp,
* [[CSS]]
* lisp
* matlab
* [[HTML]]
* [[PHP]]
* pascal
* sql
* xml

and many others. See the GeSHi homepage for full details.

=== Options ===

See the examples above. This filter is still under development so things may change.

== Demo ==

The filter has recently been installed on Moodle.org and can be seen in use there. For example see this post:

http://moodle.org/mod/forum/discuss.php?d=25413#195644

The GeSHi homepage also has an interactive demo.

http://qbnz.com/highlighter/demo.php

== History ==

This filter used to use <nowiki>...</nowiki> as markers for code. However this changed after conflicts with the HTMLArea editor became apparent.

== See also ==

* [http://moodle.org/mod/forum/discuss.php?d=25413 Forum post introducing the Filter]
* [http://moodle.org/mod/forum/discuss.php?d=43266 Forum thread for progress reports and feedback]
* [http://qbnz.com/highlighter/ GeSHi homepage]

[[Category:Administrator]]
[[Category:Filter]]

Code syntax highlighting

2006-07-18T11:12:22Z

Shinoda: New version of filter now has different embed method, updated this page to reflect that.

You can color or highlight code snippets within Moodle resources, forum posts etc. To do so you must install the GeSHi (Generic Syntax Highlighter) Filter. This makes the power of GeSHI available in Moodle through the use of a pair of special tags.

== Installing ==

You can download the GeSHi filter from here:

http://geshi.org/downloads/moodle-geshi-filter-0.1.0.zip

To install, unzip that archive into your filter/ directory and then enable it in the admin filter configuration screen.

== Instructions for use ==

Enclose your code in spans like so:

<nowiki>[code lang]your code goes here [/code]
[code lang linenumbers]your code with line numbers [/code]
[code lang highlight=1,2,6-9]your code with lines 1, 2 and 6 to 9 highlighted "extra" [/code]
[code lang linenumbers start=4]start the line numbers at "4" [/code]</nowiki>

=== Supported languages ===

* asm,
* bash,
* cpp,
* [[CSS]]
* lisp
* matlab
* [[HTML]]
* [[PHP]]
* pascal
* sql
* xml

and many others. See the GeSHi homepage for full details.

=== Options ===

See the examples above. This filter is still under development so things may change.

== Demo ==

The filter has recently been installed on Moodle.org and can be seen in use there. For example see this post:

http://moodle.org/mod/forum/discuss.php?d=25413#195644

The GeSHi homepage also has an interactive demo.

http://qbnz.com/highlighter/demo.php

== History ==

This filter used to use <nowiki>...</nowiki> as markers for code. However this changed after conflicts with the HTMLArea editor became apparent.

== See also ==

* [http://moodle.org/mod/forum/discuss.php?d=25413 Forum post introducing the Filter]
* [http://moodle.org/mod/forum/discuss.php?d=43266 Forum thread for progress reports and feedback]
* [http://qbnz.com/highlighter/ GeSHi homepage]

[[Category:Administrator]]
[[Category:Filter]]

Moodle in education

2006-03-31T00:58:27Z

Shinoda: spelling mistake

__NOTOC__
==Getting started==

This guide will help teachers who need to set up their courses in Moodle. Moodle is an Internet program that allows teachers and students to work together to learn a subject. Moodle can be used to present the course material, reference other material, collaborate, quiz, submit assignments, and provide feedback on course material.

To begin building your courses: 
1. Access the Internet in the way you usually do. Moodle supports most major Internet Browsers and systems. 
2. Enter the Internet address of your schools Moodle site. This address will probably have been provided to you by your schools Tech Support department. (Common addresses are; www.yourschool.com/moodle, www.yourschool.edu/moodle, etc...) 
3. At the top right of the Moodle window is a button provided for you to log-in. Click the button. 
4. Fill in the Username box, then click on the Password box and fill it in with the password given to you by your Tech department. 

If the log-in is successful you will probably be presented with a blank course page. If it is not successful then you should check a couple of things. 
1. Is the Caps-Lock key on your keyboard ON? 
2. Have you typed the Username and Password in verbatim? Case does matter in some systems. 
3. Has your Tech Support department issued you a Username and Password? 

Now onto the nitty gritty. You will find the [[Course homepage|course homepage]] is broken down into [[Course sections]]. A course is created by [[Adding resources and activities|adding resources and activities]]. When writing text in Moodle you have a range of [[Formatting options]] including using [[HTML in Moodle]]

==Editing A Course==

To add or alter activities or resources you will need to [[Turn editing on|turn editing on]]. You can do this by pressing the button at the top right of the course homepage or following the turn editing on link in the administration block. You can turn editing off again by pressing the button or the admin block link again (now renamed turn editing off)

When editing is on you will see the following icons:

:[[Image:Edit.gif]] - the edit icon lets you alter/upadate whatever resource or activity it is next to.

:[[Image:Help.gif]] - the help icon will popup a relevant help window

:[[Image:Open.gif]] - the open-eye icon means an item is visible to students. It will close when you click on it

:[[Image:Closed.gif]] - the closed-eye icon means an item is hidden from students. It will open when you click on it.

:[[Image:Right.gif]] - the left icon is used to indent course elements. There is also a right icon.

:[[Image:Move.gif]] - the move icon allows course elements to be placed anywhere

:[[Image:Movehere.gif]] - the move here icon appears when moving a course element.

:[[Image:Delete.gif]] - the delete icon will permentantly delete something from the course

:[[Image:Marker.gif]] - the marker icon allows you to make a section current

:[[Image:One.gif]] - the one icon hides all other sections

:[[Image:All.gif]] - the all icon redisplays all sections in a course

If you are running version 1.6 or above you will see a '''Student View''' toggle button at the top right of the course homepage. This allows you to see the course exactly as your students will see it.

==Activity modules==

There are a number of interactive learning [[Modules (teacher)|activity modules]] that you may [[Adding_resources_and_activities | add to your course]].

Communication and collaboration may take place using [[Chats]] and [[Forums]] for conversational activities and [[Choices]] to gain group feedback. Adding [[Wikis]] to your courses is an excellent way to allow students to work together on a single piece.

Work can be submitted by students and marked by teachers using [[Assignments]] or [[Workshops]]. Automatic marking can be achieved by using [[Quizzes]]. You can even integrate your Hot Potato quizzes by adding a [[Hotpot]] activity.

Content may be delivered and supported using [[Lessons]] and [[SCORM]] activities. Key words can be added to [[Glossaries]] by yourself of, if you allow it, your students.

[[Surveys]] and [[Database module|Databases]] are also very powerful additions to any course.

If all of that isn't enough for you then you can also [[Non-standard modules|add other modules]] that are not part of the official Moodle release!

==Resources==

Moodle supports a range of different [[Resources|resource types]] that allow you to include almost any kind of digital content into your courses. These can be added by using the [[Adding_resources_and_activities | add a resource]] dropdown box when editing is turned on.

A [[Text page]] is a simple page written using plain text. Text pages aren't pretty, but they're a good place to put some information or instructions. If you are after more options for your new page then you should be thinking about adding a [[Web page]] and making use of Moodle's WYSIWYG editor.

Of course the resource may already exist in electronic form so you may want to [[File or website link|link to an uploaded file or external website]] or simply display the complete contents of a [[Directory|directory]] in your course files and let your users pick the file themselves. If you have an [[IMS content package]] then this can be easily added to your course.

Use a [[Label|label]] to embed instructions or information in the course section.

==Blocks==

Each course homepage generally contains blocks on the left and right with the centre column containing the course content. Blocks may be added, hidden, deleted, and moved up, down and left/right when editing is turned on.

A [[Blocks (teacher)|wide range of blocks]] exist that provide additional information or functionality to the learner or teacher. These are included with the standard Moodle package but a range of [[Non-standard blocks]] exist which an administrator can add.

===Administration Block===

All of the links in the administration block are only available to teachers of the course. Students will receive their own version of the block which will display a link to their own gradebook and, if enabled, their own course logs.

Features in the administration block allow teachers to manage [[Students | student]] and [[Teachers | teacher]] enrollments and their [[Groups | groups]], view the course [[Grades | gradebook]], create custom [[Scales | grading scales]] and access the Teacher forum. The teacher forum is a private forum only available to teachers of that course. It can be used to discuss the course content, the direction the course could take or even to attach files to that can be shared among the course teachers.

You can change the way students (and other teachers) access and view your course by exploring the [[Settings]] option in the [[Administration | administration block]].

There are lots of possible ways to set up a course using the but teachers may be particularly interested in [[Settings#Format | course formats]] which change how the course is presentated the learner. The weekly format is suitable for courses that have a clear start date and activities are presented in weekly blocks. Topic formatted courses are actually presented in a similar way but with the dates removed so activities can belong to general or specific areas of study. The social format doesn't use much content at all and is based around just one forum which is displayed on the main course page.

In the course homepage there is a white square icon on the top right of a [[Course_sections | section]] which can be used to expand and collapse sections. You can also use the lightbulb icon to mark a topic as current.

Another much used feature of the adminstration block is the [[Files]] link. From here you can upload any digital content for inclusion in an activity, resource, course section or for a direct download. These files can be moved, renamed, edited directly on the server (if they are HTML or text) or deleted. You can also create a directory and display the whole contents of that directory to course students using the add resource drop down in any course section.
Of course if your content resides out on the web then you don't need to upload the files at all - you can link directly to them from inside the course using the link to file or website option.

==General Advice==

* Subscribe yourself to all the forums so you keep in touch with your class activity.
* Encourage all the students fill out their user profile (including photos) and read them all - this will help provide some context to their later writings and help you to respond in ways that are tailored to their own needs.
* Keep notes to yourself in the private "Teacher's Forum" (under Administration). This is especially useful when team teaching.
* Use the "Logs" link (under Administration) to get access to complete, raw logs. In there you'll see a link to a popup window that updates every sixty seconds and shows the last hour of activity. This is useful to keep open on your desktop all day so you can feel in touch with what's going on in the course.
* Use the "Activity Reports" (next to each name in the list of all people, or from any user profile page). These provide a great way to see what any particular person has been up to in the course.
* Respond quickly to students. Don't leave it for later - do it right away. Not only is it easy to become overwhelmed with the volume that can be generated, but it's a crucial part of building and maintaining a community feel in your course.
*Don't be afraid to experiment: feel free to poke around and change things. It's hard to break anything in a Moodle course, and even if you do it's usually easy to fix it.
* Use the navigation bar at the top of each page - this should help remind you where you are and prevent getting lost

== See also ==
*[[Teaching with Moodle]]
*[[Teaching do's and don'ts]]
*[[Presentations]]
*[[Moodle manuals]]
*[[Using Moodle book]]

[[Category:Teacher]]
[[es:Documentación para Profesores]]
[[fr:Documentation enseignant]]
[[nl:Documentatie voor leraren]]