Migrating logging calls in plugins

This document is aimed to assist developers in replacing existing add_to_log() calls in the plugin with the events. This can be implemented in Moodle 2.6 and this must be done in 2.7.

As a quick reminder: Event 2 was introduced in Moodle 2.6, new Logging 2 system is being introduced in Moodle 2.7. Function *add_to_log()* becomes deprecated. Log storage that uses the DB table *log* is now called "legacy". When replacing the add_to_log() with triggering of an event developer also must ensure that he also generates an entry to the legacy log. It will only be used if legacy log is enabled since it may be enabled on systems that use too many custom reports relying on presence of log table and it would take time to migrate the reports.

Quick guide

If you are replacing common add_to_log() calls such as "view" and "view all" in mod/XXX/view.php and mod/XXX/index.php, see below. Otherwise do the following:

Choose a name for event

It should have syntax OBJECT_VERB, for example "entry_added", "content_viewed", etc. It should not have plugin name in it because it is obvious from namespace. See Event 2 for more details on events names.

Define language string for the event name in YOURPLUGINDIR/lang/en/FULLPLUGINNAME.php :

$string['eventSOMETHINGHAPPENED] = 'SOMETHING has HAPPENED';

Create event class

It must be located in YOURPLUGINDIR/classes/event/SOMETHING_HAPPENED.php , typical example:

namespace FULLPLUGINNAME\event;
defined('MOODLE_INTERNAL') || die();
class SOMETHING_HAPPENED extends \core\event\base {
    protected function init() {
        $this->data['crud'] = 'c'; // c(reate), r(ead), u(pdate), d(elete)
        $this->data['edulevel'] = self::LEVEL_PARTICIPATING;
        $this->data['objecttable'] = '...';
    }

    public static function get_name() {
        return get_string('eventSOMETHINGHAPPENED', 'FULLPLUGINNAME');
    }

    public function get_description() {
        return "User {$this->userid} has ... ... ... with id {$this->objectid}.";
    }

    public function get_url() {
        return new \moodle_url('....', array());
    }

    public function get_legacy_log_data() {
        return array($this->courseid, 'PLUGINNAME', 'LOGACTION',
            '...........',
            $this->objectid, $this->contextinstanceid);
    }
}

Trigger event instead of add_to_log()

Replace add_to_log() with triggering of event. This is a common example for event inside an activity module:

add_to_log($course->id, 'PLUGINNAME', 'LOGACTION', '...........', $objid, $cmid);

with:

$event = \FULLPLUGINNAME\event\SOMETHING_HAPPENED::create(array(
    'objectid' => $objid,
    'context' => context_module::instance($cmid)
));
$event->trigger();

Replacing 'view' event in the modules

This is usually found in mod/PLUGINNAME/view.php (or in lib function included from this file) and indicates that user viewed the module.

Defining class

YOURPLUGINDIR/classes/event/course_module_viewed.php :

namespace mod_glossary\event;
defined('MOODLE_INTERNAL') || die();
class course_module_viewed extends \core\event\course_module_viewed {
    protected function init() {
        $this->data['objecttable'] = 'PLUGINNAME';
        parent::init();
    }
    // You might need to overwrite get_url() and get_legacy_log_data() if view mode needs to be stored as well.
}

Triggering event

This example takes data from $PAGE object but you may as well substite with ids and objects that you fetched:

$event = \FULLPLUGINNAME\event\course_module_viewed::create(array(
    'objectid' => $PAGE->cm->instance,
    'context' => $PAGE->context,
));
$event->add_record_snapshot('course', $PAGE->course);
$event->add_record_snapshot($PAGE->cm->modname, $activityrecord); // You can use $PAGE->activityrecord if you have set it, avoid unnecessary DB queries (see [[#add_record_snapshot|add_record_snapshot()]])
$event->trigger();