Notifications/Developer guide

Notifications, as enabled by the Echo Extension, give MediaWiki users quick updates about actions that affect them. These notifications can help users become more aware of events that relate to them and take quick action if they want to.

This document is intended for MediaWiki extension developers and describes how to extend a MediaWiki extension to use the Notifications system. Currently, the following MediaWiki extensions are using the Echo extension to send notifications:


 * Thanks, to send thanks notifications to users for specific revisions.
 * PageTriage, to send notifications that indicate whether a page is reviewed and approved, reviewed with issues, or reviewed and nominated for deletion.
 * EducationProgram
 * Flow
 * GettingStarted (removed in January 2014)
 * LiquidThreads (in the code, but commented-out)
 * OpenStackManager (Only on WikiTech)

Message contents are listed at Echo (Notifications)/Message audit.

For more information about the Notification system, please see the project home page.

See also: Echo (Notifications)/API

Notification categories
Every notification must be assigned to a category, which defines the notification preferences (e.g., opt-in or opt-out; on-wiki or email notification). The notification category can also be used to specify user groups that are eligible to receive the notification, the priority of the notification, and a help tip. Note that multiple notifications can be assigned to a single category.

The assigned category can be one that is predefined by the Echo extension, or a customized category. Predefined categories include:

Creating a new category
Each category definition consists of an array of keys and values. The following is an example of a category definition used by the Thanks extension:

You'll also need to set the title of the category in your i18n file - the message key must be of the form "echo-category-title-":

Notification category parameters
Note that all category parameters are optional.

Defining a notification
Each notification consists of, at minimum, a title and a timestamp. In addition, a notification may also include a payload and primary and secondary action links.

Title: The title is a simple string that conveys a piece of information to a user. It may include links, or may have no data or link associated.

Timestamp: The timestamp reflects the time the notification was generated.

Primary action link: A link designated as the main action that the user should take in response to a notification. In the flyout interface (the overlay revealed when you click the red notifications badge), the entire notification is clickable and the destination the user is sent to when clicking the notification is defined as the primary link.

Secondary action link: An additional link that may be needed for a notification. Most notifications will not have a secondary link and the use of secondary links is discouraged (to keep the interface simple).

Payload: The payload contains secondary data that augments the notification, e.g., an edit summary or a snippet of content such as the first few words of a contribution.

The notification appears in the flyout menu beside the user name as well as on the user’s Notification page and, if email notification preference is set to on, as an email message. Note that the notification can be customized for each of these instances via the notification parameters.

TODO: Explain more about customizing for different views

Each notification definition consists of an array of keys and values. The following is an example of the Thanks notification definition. Note that the notification and the category have the same name (‘edit-thank’), as the Thanks notification is the only notification for this category:

Notification parameters
* Will become optional soon

Predefined icons
The following icons are defined by the Echo extension and may be used by additional notifications.

From: https://github.com/wikimedia/mediawiki-extensions-Echo/tree/master/modules/icons

Additional icons
The following icons are used by other extensions deployed on Wikimedia sites.

Creating a new icon
Notification icons should be 30x30 pixel monochrome graphics that use the following color scheme:
 * Black for negative actions
 * Green for positive actions
 * Blue for neutral actions

Adding an icon
Add icons in hook Add icons in global variable

Payloads
A payload adds more descriptive detail to a notification, it is usually located below the notification title in flyout/archive page/email.

Notification formatter classes
The formatter class is the engine that defines how to turn an event into a message that the end-user reads. The value should be set to the name of a PHP class (either predefined or customized).

Predefined formatter classes
Formatter class provides an abstraction to format and display notification message for all distribution types: flyout, archive page, email and any other future distribution types. A notification only needs to define the messages and parameter tokens for each distribution type, all the formatting work will be handled automatically by the formatter class. There are three pre-defined concrete formatter classes: EchoBasicFormatter, EchoEditFormatter and EchoCommentFormatter, the basic formmater defines common and general parameter tokens for flytout, archive, and email while edit and comment formatter have more specific tokens for edit and comment related actions

Creating a new formatter class
New formatter classes can be developed as part of your extension and referred to via the notification’s 'formatter-class' parameter.

New classes should extend one of the predefined formatter classes and should have a processParam function, which defines how to handles the message parameters unique to your notification. The following example is from the Thanks extension:

Individual email notification
A typical individual email notification consists of four major components: intro, summary, call-to-action and footer


 * intro: the message defined in either 'email-body-batch-message' or 'email-body-batch-bundle-message' for the notification
 * summary: by default, it's the revision snippet if there is any. A notification could provide it to event 'extra' param with 'section-text' key.  A notification could also overwrite getRevisionSnippet method to provide some other custom summary.
 * call-to-action: the message defined in 'primary-link' and 'secondary-link' if any
 * footer: the message defined in either 'echo-email-footer-default-html' or 'echo-email-footer-default'

HTML email also contains an icon component

Batched email notification
A user can request to receive notification summary in email once in a day or a week. For the summary section in the notification, the message defined in 'email-body-batch-message' is used. For a bundled message, the message defined in 'email-body-batch-bundle-message' is used

Bundled notifications
Notification can be triggered anywhere from the code. We definitely do not want to spam the user with notifications. In this case, we may want to enable notification bundling. For example, page-link notification is triggered when a page is linked from another page, a popular page may trigger a lot of unwanted notifications. Bundling will help resolving the problem

Hook the notification into the Echo extension
To hook your notification to the Echo extension, use the following two hooks:

BeforeCreateEchoEvent - Used to pass Echo your definition for the notification category and the notification itself (as well as any custom icons).

Example from Thanks: EchoGetDefaultNotifiedUsers - Used to define who gets the notifications (for example, the user who performed the edit)

Example from Thanks:

Remember to register the above hooks to your myCoolExtension.php file. Example from BounceHandler:

Create the notification via the Echo extension
To trigger the notification, use the EchoEvent::create function call, either as part of the extension code (if the extension creates an interface) or in a hook to an existing part of the MediaWiki software. The EchoEvent::create function defines what data gets passed in to the notification.

The following example is used by the Thanks extension: All create function calls must have a 'type' parameter; the rest of the parameters are optional and depend on the notification.

Opt-in is best
In general, notifications should be opt-in unless they are a critical component of site building and it’s imperative that everyone get them.

You can set defaults for opt-in or opt-out via $wgDefaultUserOptions.

For example your category has the name myCategory the definition would look like:

Categorydefinition

The value for useroptions is echo-subscriptions-typeOfNotification-categoryOfNotification.

Opt-in

Opt-out

Rate-limit notification-generating events
To prevent users from getting spammed by your notification, you can rate-limit the event that generates the notification (e.g., limit a user to 10 or fewer thanks events per minute).

Monitoring
Echo uses EventLogging to track data about notifications. Some graphs of notification data can currently be found at:
 * http://ee-dashboard.wmflabs.org/dashboards/features/#notifications-graphs-tab
 * http://toolserver.org/~dartar/en/echo/
 * http://toolserver.org/~dartar/mw/echo/