Extension:EventLogging/Programming


 * See ../Guide for a comprehensive introduction to EventLogging, developing and deploying EventLogging schemas, and more.

How it works
After you have created a schema, you must register it, by using the $wgEventLoggingSchemas configuration variable (or the EventLoggingRegisterSchemas hook if it needs to be done dynamically). For an extension supporting extension registration, that would mean adding something like to  (in this example the schema is GettingStarted;   is the schema revision ID).

This automatically creates an mw.track topic you can send event data to; EventLogging will of logging them:

If you only want to log data on the server side, there is no need to register the schema. You can log an event like this:

Versioning
If code tries to log an event that doesn't match the data model that EventLogging retrieved, EventLogging will log the event anyway but flag it as invalid. Since you always give a schema revision, you can edit the schema as much as you want without affecting existing code.

It's OK to have different kinds of events (often called actions) sharing one data model. That way the events go into one table and it may simplify querying and multi-dimensional analysis. Only add  to the fields that are applicable to all events.

Data fields

 * ''moved to ../Guide

Available data models
See m:Category:Schemas (active).

JSON schema validation
Each data model JSON file on meta-wiki is a JSON schema. This is an evolving standard to specify the format of JSON structures, in our case the logged event.
 * the JSON schema draft.
 * When code attempts to log an event, EventLogging only pays attention to a subset of JSON schema features, including:
 * type: boolean, integer, number, string, array, object
 * required: true/false
 * enum values
 * For details, see schemaschema.json.

Good starting code

 * The WikimediaEvents extension has working code to log server-side events in PHP in.

Client-side logging

 * require your schema wherever you need to log events (it will pull in the  module which contains the   object).
 * See for API documentation.

Tips

 * In JavaScript code, use  to set common values for fields to log that don't change, such as version, the user's name, etc.
 * ../Guide lists common field names already used in schemas and the JavaScript that fills them. Don't reinvent the wheel.

Debugging
If code attempts to log an invalid event, EventLogging logs it anyway. If you want to enable informational validation (does not affect logging) see: https://www.mediawiki.org/wiki/Extension:EventLogging/Guide#See_logging_in_your_browser. If the logged event has a revision of -1, it's possible you haven't registered your Schema correctly.

Monitoring events

 * Client-side event logging works by sending a beacon request (falling back to a beacon image request) to  with the the JSON-encoded event capsule in its query string.  To see the log events you can
 * watch for this request in your browser's network console,
 * look for it in your web server's access logs, or
 * run the toy web server server/bin/eventlogging-devserver in the EventLogging extension which pretty-prints the query string.


 * An alternative to the above is to enable the more user-friendly debugging UI introduced in . Currently, the debugging UI is shipped to all users but is enabled via a hidden user preference, which can only be set by pasting the following into your browser's JavaScript console:
 * To monitor events after processing, you can append an  callback after a   call, for example:

Logging clicks on links
Often you want to log clicks on links. If these take the user away from the current page, there's a chance that the browser will move to the new page before the request for the beacon image makes it onto the network, and the browser will drop the request. The E3 team experimented with using deferred promises to deal with this, but that introduced known and unknown unknowns. is related to this issue.

There are significant performance concerns regarding logging before showing the next page and our recommendation is not to do that until the new beacon API becomes available. Details on performance issues can be found here: https://bugzilla.wikimedia.org/show_bug.cgi?id=52287