Student projects/Further messaging improvements
The messaging system in 2.0 has been revamped significantly. It is now event-driven, and allows users to control exactly what messages they receive and how.
How to enable it
Admin > Optional subsystems > Enable messaging system = Yes
How to configure it
Visit your own profile page (you need moodle/user:editownmessageprofile permission). Note that the types of messages listed in the "Configure destinations for incoming messages" box is determined by the contents of the message_providers table.
How it works
Providers (input)
We have Events called "message_send" that look like this:
<syntaxhighlight lang="php"> $eventdata = new object(); $eventdata->component = 'mod_forum'; // the component sending the message. Along with name this must exist in the table message_providers $eventdata->name = 'posts'; // type of message from that module (as module defines it). Along with component this must exist in the table message_providers $eventdata->userfrom = $userfrom; // user object $eventdata->userto = $userto; // user object $eventdata->subject = $postsubject; // very short one-line subject $eventdata->fullmessage = $posttext; // raw text $eventdata->fullmessageformat = FORMAT_PLAIN; // text format $eventdata->fullmessagehtml = $posthtml; // html rendered version $eventdata->smallmessage = ; // useful for plugins like sms or twitter
events_trigger('message_send', $eventdata);
The name of each provider is a string with a name like messageprovider:$name from the component lang file (in this case, forum.php is derived automatically from mod/forum):
<syntaxhighlight lang="php"> $string['messageprovider:posts'] = 'Subscribed forum posts'; $string['messageprovider:digests'] = 'Subscribed forum digests';
More providers can be added throughout Moodle as necessary, it's quite easy. See the Old Events API for info.
Processors (output)
In /message/output there are full Moodle plugins for each type of output.
Currently we have support for email, jabber and web-based popups. Could add twitter and SMS quite easily.
Each plugin simply extends a class called "message_output" in /message/output/lib.php with methods such as:
<syntaxhighlight lang="php"> function send_message($message) {
// Given a message object and user info, this actually sends it.
}
function config_form($preferences) {
// This defines the little form fragment on the config page
}
function process_form($form, &$preferences) {
// This processes the data from the config form fragment
}
function load_data(&$preferences, $userid) {
// This loads up prefs for this plugin
}
It should also provide a messageprocessor_xxxxx.php language file (where xxxxx is the name) and inside is an xxxxx string with the name of the processor, like this:
<syntaxhighlight lang="php"> $string['jabber'] = 'Jabber message';
Finally, there should be a lib.php file containing an install routine to install itself as a message processor:
<syntaxhighlight lang="php"> function jabber_install(){
global $DB;
$result = true;
$provider = new object(); $provider->name = 'jabber'; if (!$DB->insert_record('message_processors', $provider)) { $result = false; } return $result;
}
And a version.php file: <syntaxhighlight lang="php"> $plugin->version = 2008090900; $plugin->requires = 2008091500;
See also
- GSOC/2008
- Messaging improvements, a GSOC 2007 project
- Old Events API
- MDL-10107