Code / Appnel Solutions 

Activity Log Classes in MT4

Developing a new plugin, I found a new quirk in MT4 and how it handles specialized activity log class for plugins. This can be a really useul means of monitoring the health of the system and identifying issue when they occur.

The activity log classes allow plugins to record metadata that is specific to its operation and then filter those entries from the rest of the log. Users can use the Activity Log interface to get this information or subject to a feed containing information about this specific type.

To create a log class In MT 3.3 you would subclass MT::Log and then overload the appropriate methods that uniquely identify you log class and provide its unique functionality. Here is an example from the MT 3.3 code:

package MT::Log::Entry;

@MT::Log::Entry::ISA = qw(MT::Log);

sub class_label { "Entries" }
sub description {
    # what is in here doesn't matter to the example.
}

Creating the log class isn't enough though. MT needs to know about it so you need to register it in one of two ways. Either use the add_log_class API method or a HASH log_classes key when creating your plugin.

# using API method
MT->add_log_class('MyCustomLog');

# HASH method when constructing your plugin object.
MT->add_plugin({
    name => "My custom plugin",
    log_classes => { customlog => "MyCustomLog" }
});

While under documented (surprise!), this is pretty straight-forward stuff as far as plugin development goes.

As I found out recently and despite the embedded documentation, this does not work in MT4.

Creating a specialized log class is not only different, but the MT3 way will not work at all. I guess Six Apart assumed no one had taken advantage of this feature (I did) or deemed it not part of the plugin API (it is). Working on a new plugin I figured out how MT4 log classes need to be handled.

In MT4 you subclass MT::Log as before, but you also must define a class_type property. The class_type MUST be unique to any other log class in the system. I suggest following the same naming convention as MT itself. The plugin id or object type in lowercase. Here is how MT::Log::Entry looks in MT 4.01:

package MT::Log::Entry;

our @ISA = qw( MT::Log );

__PACKAGE__->install_properties({
    class_type => 'entry',
});

sub class_label { MT->translate("Entries") }

sub description {
    # what is in here doesn't matter to the example.
}

Once again, creating the log class is not enough. Rather then register it using a method like add_log_classes or the log_classes key, MT4 requires you to make a object_types entry in the registry.

object_types:
    log.entry: 'MT::Log::Entry'

Like any other MT object you define a class type (model name) and give the package (class) name that is associated with it. I suggest following the same naming convention as MT itself and using the plugin ID or object type in lowercase prefixed with 'log.' like in the example above.

Typically, when defining an object type, you need to define a schema version and the update system will run when the plugin is first installed, but this is not the case here. Your specialized log class is not changing or adding to the database schema so neither of these are required.

Now with your MT::Log subclass defining a unique class_type and registering itself as an object in the system, you can now log and filter entries in the activity log tailored for your plugin.