Jump to content

Extension:ContributionAnalytics

From mediawiki.org
MediaWiki extensions manual
ContributionAnalytics
Release status: experimental
Implementation Special page , Parser function , API
Description Provides statistics and charts of wiki contribution activity.
Author(s) PetraMagnatalk
Latest version 0.1.0
MediaWiki 1.43+
Database changes Yes
Licence GNU General Public License 3.0 or later
Download

The ContributionAnalytics extension provides statistics and charts of wiki contribution activity through:

  1. A special page with an interactive chart showing trends such as the number of edits and number of editors per day/month.
  2. A parser function for embedding charts from the special page.
  3. A parser function for GitHub-style contribution heatmaps.
  4. An API module for programmatic access to the raw data.

Installation

[edit]
  • Download and place the file(s) in a directory called ContributionAnalytics in your extensions/ folder.
  • Add the following code at the bottom of your LocalSettings.php file:
    wfLoadExtension( 'ContributionAnalytics' );
    
  • Run the update script which will automatically create the necessary database tables that this extension needs.
  • Run the following command once to backfill the cache from existing edits:
    php maintenance/run.php ContributionAnalytics:RebuildContributionAnalytics
    
  • Yes Done – Navigate to Special:Version on your wiki to verify that the extension is successfully installed.

Usage

[edit]

Special page

[edit]

Special:ContributionAnalytics renders an interactive chart with controls to change the metric, bucket, date range, and threshold.

Parser functions

[edit]
An example heatmap generated by the extension.
{{#contribution_tiles}}

Renders a GitHub-style contribution heatmap (one tile per day).

{{#contribution_tiles: Example user}}
  • First positional parameter (or user=): show tiles for the named user. An empty value or an unrecognized username falls back to site-wide statistics.
  • start / end: date range in YYYY-MM-DD or YYYYMMDD format. Defaults to the past year. The range may not exceed 2 years for performance reasons. Please call the parser function multiple times instead. Example: |start = 2024-01-01.
  • title: overrides the heading above the grid.
  • summary: overrides the text below the grid. $1 is substituted with the total edit count in range. Example: | summary = $1 {{PLURAL:$1|edit|edits}} in 2024.
An example plot generated by the extension
{{#contribution_plot}}

Embeds the same interactive chart used on the special page.

{{#contribution_plot:
| metric = edits
}}
  • metric: edits (default), editors, or threshold (number of distinct users meeting threshold edits in the bucket).
  • bucket: day or month (default).
  • start / end: date range, same YYYY-MM-DD or YYYYMMDD format.
  • threshold: minimum edit count for the threshold metric. Default 10.
  • segments: comma-separated list restricting which series are shown: anon, registered, and total. Shows all series if omitted.
  • controls: unlike the special page, the interactive control panel is hidden by default in transcluded charts. Set this to true to display it.

Both parser functions are expensive and count against $wgExpensiveParserFunctionLimit.

How it works

[edit]

Edit data is aggregated into a ca_daily_actor_edits table. The API, special page, parser functions all query from this table instead of directly from the revision and actor tables. This caching table is updated whenever a page is saved, which triggers a deferred update.

The cache can get out of sync with the revision table due to page deletions, undeletions, imports, and other means to insert or delete revisions without editing. Run the RebuildContributionAnalytics maintenance script to rebuild it from scratch. This will happen automatically if you run updateSpecialPages.php. If you are on Miraheze, simply disable and re-enable the extension on ManageWiki to trigger it manually.

Because a page may become stale as the parser cache could stay untouched for weeks, when a range includes today or yesterday, the parser functions in this extension set a shorter parser cache expiry for the page (24 hours).

See also

[edit]