Writing log managers

Moodle 2.7

This is an advanced developer documenation.

For majority of sites the log manager provided with Moodle standard distribution should be sufficient, and you would rarely need to implement a new log manager. Think really hard before you decide to go for a new logmanager, You would need it only if you want to radically change the behaviour of how logs work with Moodle.

So you decided to go for a new logmanager. Now let us get started with implementing it:-

You shall not pass

Writing a logmanager needs advanced understanding of how certain things work in Moodle. Please make sure you are fully familiar with following concepts and their implementation in Moodle, before moving forward:-

• Automatic class loading
• Namespaces
• Events API
• Logging 2
• Migrating logging calls in plugins
• Migrating reports accessing logs

Steps to write a log manager

Although it is not required, but the best way to add a logmanager is by creating a new admin tool. Let us call this as 'mylog' admin tool.

Let us get started

The first thing needed is a manager class that implements the interface \core\log\manager . Let us call our class as tool_mylog\log\manager which would be located in admin/tool/mylog/classes/log/manager.php

namespace tool_mylog\log;

defined('MOODLE_INTERNAL') || die();

class manager implements \core\log\manager {

   /**
    * Return list of available log readers.
    *
    * @param string $interface All returned readers must implement this interface.
    *
    * @return \core\log\reader[]
    */
   public function get_readers($interface = null) {
          // code for fetching instances of readers installed in the site.
   }

   /**
    * Dispose all initialised stores.
    * @return void
    */
   public function dispose() {
        // Dispose off all instances of stores.
   }

   /**
    * For a given report, returns a list of log stores that are supported.
    *
    * @param string $component component.
    *
    * @return false|array list of logstores that support the given report. It returns false if the given $component doesn't
    *      require logstores.
    */
   public function get_supported_logstores($component) {
          // You can use the callback report_x_supports_logstore() here
   }

} Besides those methods you might also want apis to manage writers and potentially a process to write logs using those writers. There are no core limitation on how to implement that.

I am watching you

So we got our manager class up, but it is useless unless it monitors events. We need to setup an observer for monitoring the events we are interesed in. For this we first create a class \tool_log\mylog\observer located in admin/tool/mylog/classes/log/observer.php namespace tool_log\log;

defined('MOODLE_INTERNAL') || die();

class observer {

   /**
    * Redirect all events to this log manager, but only if this
    * log manager is actually used.
    *
    * @param \core\event\base $event
    */
   public static function store(\core\event\base $event) {
       $logmanager = get_log_manager();
       // Process the event.
   }

} Once we got the observer in place, now we need to tell Moodle about it. We do this by adding an entry in admin/tool/mylog/db/events.php $observers = array(

   array(
       'eventname' => '*',
       'callback'  => '\tool_mylog\log\observer::store',
       'internal'  => false, // This means that we get events only after transaction commit.
       'priority'  => 1000,
   ),

);

Do you know me?

Now we need to tell Moodle about our logmanager, so it doesn't go looking for the standard manager. We do this by adding the following line to the config.php

define('LOG_MANAGER_CLASS', '\tool_mylog\log\manager');