David Scotson

I'd be interested in these too, thanks.

The parameters are mostly intended to send people to differnt links depending on who, and where, you are within Moodle.

For example, you could link to Google and pass the current user's surname as a parameter. This means every (logged in) user will see a different search result based on their name. That would look like this:

http://www.google.com/search

parameter: Surname, variable name:q

http://www.google.com/search?q=Cordella

More usefully you could take them to a map of their location:

http://maps.google.com/maps

parameter: City/town, variable name: q

http://maps.google.com/maps?q=London

In the case of course-id, if you choose id as the parameter then for the front page '1' will be added, paired with whatever parameter name you choose. This is unlikely to be useful on the front page where you would be better just copying the URL, but perhaps you have all your notes or exams on a seperate web server with urls like:

http://www.example.com/notes?course=econo101

you would be able to make a course template that could be dulplicated many times and automatically changes where the link points to whenever someone changes the course details.

I don't know if there is a place to set the upload limit but I'm fairly certain that the user image (no matter how large it is when uploaded) is always transformed into a 100x100 pixel JPG, which is never going to be more than a few K, and the original is then discarded. So people uploading massive images are mostly inconveniencing themselves (though I'm wondering how the relevant PHP image conversion routines would react to a 50M image).

Regarding a Syntax Highlighting 'resource', instead/as well as a filter: in Moodle most content is either a Resource or an Activity. It's a bit of an artificial split, but generally resources are more text for reading alone and activities more social/interactive.

Both are modular and people have created all sorts of esoteric add-ins for various purposes which, when installed, appear in the little "Add a something..." drop down lists when you're in editing mode.

Current different types of resource include:

• text
• html page
• display file
• show directory
• link to website

So with a hypothetical Syntax Highlighting resource, you would first have an admin either install it (or switch it on if it becomes a standard part of Moodle). Then you would select 'Add code listing' from the 'Add a resource...' drop down.

This would take you, as the other resources currently do, to a page where you could give it a title, short description and write or paste in the actual content, a bit of code in this case.

The big difference would be that below that you could have a bunch of options that could get passed through to Geshi e.g. linenumbers checkbox, a drop-down for choice of language etc.

The other benefit is you could (I believe) do what the current plain text format appears to do and not bother calling any other filters before or after Geshi.

I don't think it would replace the need for filtering within longer texts, or in wikis, forum posts etc. but I think for longer pieces of code you'd be as well adding any commentary text as code comments and putting the whole thing up as a code resource.

(One final thought, you could also provide a direct download link which provides the content as an actual (un-numbered, non-highlighted) file which would prevent cut and paste weirdness and work around the numbered list bug in Firefox.)

If syntax coloring within wikis is important for you, it might be worth looking at the newer dfwiki that is scheduled, if ready, to become the new wiki module for the 1.7 release. It apparently supports the <nowiki> tags.

I don't really use either much, but I think that the older erfurtwiki has somewhat languished in the shadow of the new dfwiki that has unfortunately taken longer to arrive than originally planned.