Completely untested by me but it LOOKS like it should work. It's quite
standalone, and is basically a single function call during the restore
precheck which looks in the backup to see if it's a BB file, then
converts it using XSLT.
Apart from a little tidyup and renaming, I added a check so that it
should just silently fail if XSLT functions aren't available
Many thanks to Ziba Scott <ziba@linuxbox.com> who wrote it!
The format for each page is now the same as the id attribute of the
BODY tag, which in turn is a simple function of the script's relative path:
The format for e.g. a quiz view page is "mod-quiz-view". The format for the
site index is "site-index". Exception: the format for courses is not just
"course-view", but "course-view-weeks" etc.
Obviously the applicable_formats() override for each block should now take
this into account. The matching rules now are:
* You can specify the full format, e.g. "mod-quiz-view" => true
will allow the block to be added in quizzes
* Prefixes match the full page format, e.g. "mod" matches ALL activities
* You can use "*" as a wildcard, e.g. "mod-*-view" matches just the view.php
page of all activities
* These rules interoperate, thus "mod-*" is the same as "mod"
* "all" remains as a catch-all situation
This patch contains:
* email_to_user will set the envelope sender to a special bounce processing address (based on $CFG settings)
* email_to_user will accept (and set) a reply-to header, to be generated by the module calling the function.
* new functions:
* generate_email_processing_address - ALWAYS use this to generate the reply-to header. reply-to header will look like this:
(LIMIT: 64 chars total)
prefix - EXACTLY four chars
encodeded, packed, moduleid (0 for core) (2 chars)
up to 42 chars for the modules to put anything they want it (can contain userid (or, eg for forum, postids to reply to), or anything really. 42 chars is ABSOLUTE LIMIT)
16 char hash (half an md5) of the first part of the address, together with a site "secret"
* moodle_process_email - any non-module email processing goes here (currently used for processing bounces)
* bounce handling:
* config settings for bounce threshold and ratio (and whether to handle bounces at all)
* if too many bounces occur against any given user, user_not_fully_set_up will force an email address change
* associated functions (over_bounce_threshold, set_send_count, set_bounce_count)
* handling emails to noreply address (see below)
* new script - admin/process_email.php
This script needs to be called from your mail program for anything starting with the 4 char prefix described above (and optionally, the noreply address)
It will bounce emails to the noreplyaddress, with a friendly "this is not a real email address" message
It will break down and unencode the email address into moduleid and validate the half md5 hash, and call $modname_process_email (if it exists). Arguments to these functions are: $modargs (any part of the email address that isn't the prefix, modid or the hash) and the contents of the email (read from STDIN).
* associated string changes/additions
* changes in config-dist.php to give clues as to how to set this up.
MODULE WRITERS!
take a look at new functions moodle_process_email and generate_email_processing_address in moodlelib.php for ideas about how to
* encode and unencode the arguments your module needs to do the processing
* how to deal with multiple "actions" for any given module.
Martin Langhoff <martin@catalyst.net.nz> will be writing up some PROPER documentation, containing amongst other things config settings for different mail servers (this was developed against Postfix). Feel free to email me with any feedback on the code or design, penny@catalyst.net.nz. Or post on the developer fourm.
