WikiScriptSync

WikiScriptSync
Status	● Active
Version	1.1 (May 2026)
Author	Dev Jadiya
Mentor	KCVelaga (WMF)
Live tool	script-publisher.toolforge.org
Source code	GitLab
License	MIT License
Platform	Toolforge
Related proposal	CWS 2022

WikiScriptSync is a Toolforge web application that helps Wikimedia gadget developers keep their scripts in sync with their source repositories. It monitors public GitHub and GitLab repositories for changes to JavaScript (.js) and CSS (.css) files, monitors Wikimedia wiki pages directly for revision changes, and allows developers to publish updates from their repository to the wiki using their own BotPassword credentials — with a full preview before every edit.

This tool was developed by Dev Jadiya as part of the Developer Skill Development Program India 2025 under the mentorship of KCVelaga (WMF), and is a direct response to a request in the Community Wishlist Survey 2022.

The problem

JavaScript and CSS in the Wikimedia ecosystem

JavaScript and CSS are central to the Wikimedia editing experience. Gadgets built in JavaScript power some of the most widely used tools in the Wikimedia ecosystem:

Twinkle, used for vandal patrol and article maintenance, is a pure JavaScript gadget with millions of interactions per year.
HotCat, which simplifies category editing across hundreds of Wikimedia wikis, is maintained as a JavaScript gadget.
AutoWikiBrowser-companion scripts, accessibility tools, citation helpers, syntax highlighters, and dozens of other quality-of-life tools are deployed as user scripts or gadgets.

On the English Wikipedia alone, the MediaWiki:Gadgets-definition page defines over 200 active gadgets. Across all Wikimedia projects, thousands of user scripts are maintained under User:Name/script.js or User:Name/skin.css pages. The Wikimedia Commons, Wikidata, Meta-Wiki, and major Wikipedia language editions each maintain their own gadget repositories.

The developer workflow gap

Most active gadget developers work in standard code editors and maintain their scripts in public Git repositories on GitHub or GitLab. The deployment step remains entirely manual: once a change is committed, the developer must remember to copy the updated file to the corresponding MediaWiki page. This gap creates forgotten updates, stale deployments across multiple wikis, and no notification mechanism when upstream sources change.

Some developers work entirely on-wiki — writing scripts directly in their User: namespace without any external repository. These developers have the opposite problem: no way to monitor their on-wiki script pages for unexpected changes, vandalism, or edits by others.

WikiScriptSync addresses both sides of this gap.

Scope and security boundary

Following discussion with Tgr (WMF) and with stewards at Steward requests/Miscellaneous#OAuth permissions, automated JavaScript publishing via OAuth was determined to require community consensus comparable to bot approval. WikiScriptSync therefore implements publishing through each user's own BotPassword credentials rather than shared OAuth edit rights. The tool never holds sitewide JS/CSS editing permissions. Each publish uses the user's own account and their own explicitly granted permissions.

Features

WikiScriptSync provides three complementary features:

GitHub / GitLab monitoring

Add any public GitHub or GitLab repository. WikiScriptSync detects tracked .js and .css files and checks for changes hourly using Git blob SHA comparison. No file content is stored — only the 40-character hash. When a change is detected, WikiScriptSyncBot posts a notification on the maintainer's talk page on Meta-Wiki.

Wiki page monitoring

Add any Wikimedia wiki page URL — including on-wiki user scripts like User:Name/gadget.js — and WikiScriptSync monitors it for revision changes every 30 minutes. This is useful for developers who work entirely on-wiki without an external repository. A notification is sent whenever a new revision is detected.

Bot-based publishing

Connect a GitHub or GitLab file to a wiki page target, add your BotPassword credentials in Settings, and WikiScriptSync can publish the file content directly to the wiki on your behalf. Before any edit is made, a side-by-side preview shows exactly what will change. Nothing is published without an explicit confirmation. A permanent audit log records every publish attempt with the commit SHA, edit summary, and a link to the wiki diff.

How it works

GitHub / GitLab monitoring pipeline

WikiScriptSync runs an hourly scheduled job on Toolforge. For each monitored repository, it fetches the complete Git file tree using a single GitHub REST API call. Each file's blob SHA-1 hash is compared against the stored value. If the hash has changed, the file is marked as updated. No file content is fetched or stored at any point; only the 40-character hash is compared.

A tree-level signature cache skips entire repository fetches when the repository has not changed since the last run, minimising API usage. A circuit breaker pauses checks on files that fail five consecutive times and retries automatically after 24 hours.

Wiki page monitoring pipeline

A 30-minute job fetches the latest revision ID for each monitored wiki page using the MediaWiki API. If the revision ID has changed since the last check, a notification is queued. The page content is not stored — only the revision ID number is compared.

Publishing pipeline

When a user initiates a publish:

The tool fetches the current file content from GitHub or GitLab (public raw URL).
The current wiki page content is fetched via the MediaWiki API (unauthenticated read).
A side-by-side diff is displayed for review.
On confirmation, the tool decrypts the user's stored BotPassword (see Security below), establishes an isolated MediaWiki API session using that credential, submits the edit with a structured edit summary, and immediately closes the session and discards the credential from memory.
The result is recorded in the publish audit log with status, revision ID, commit SHA, and a link to the wiki diff.

Authentication

Wikimedia OAuth 2.0

Click Continue with Wikimedia on the sign-in page. This requests read-only access to your Wikimedia username. No edit permissions are requested via OAuth.

BotPassword (for publishing)

To use the publishing feature, you create a BotPassword on each wiki you want to publish to. The tool guides you through this process in the Bot Credentials settings page. You only need to check Create, edit, and move pages — sitewide JS/CSS editing rights are not required for user namespace pages and should not be granted.

Usage

Adding a repository

Enter the full public URL of any GitHub or GitLab repository. Both https://github.com/owner/repo and branch-specific URLs are accepted. Only .js and .css files appear in the file list. Private repositories are not supported.

Enabling file monitoring

After adding a repository, click On next to any file to begin tracking it. Only files with monitoring enabled will trigger notifications.

Adding a wiki page to monitor

Go to Wiki Pages in the sidebar. Enter any Wikimedia wiki page URL. The tool accepts full URLs like https://en.wikipedia.org/wiki/User:Name/gadget.js and extracts the wiki and page title automatically.

Configuring destination mappings

Each monitored file can be linked to one or more destination wiki pages. These appear in talk-page notifications and are required for publishing. The mapping form pre-fills the page title based on the filename — for example, dist/gadget-helloWorld.js suggests User:YourName/gadget-helloWorld.js.

Enabling publishing

With a destination mapping set and a BotPassword credential saved in Settings, click Enable publish next to a mapping to enable publishing for that file. Then click Publish to wiki to open the preview page, review the diff, and confirm.

Notification format

When a change is detected, the maintainer receives a structured talk-page message naming the changed files, the source repository, the mapped destination pages, and a link to the dashboard.

Notification preferences

The minimum interval between notifications for the same file is configurable in Settings. The default is 6 hours. The maximum is 168 hours (one week).

Security and privacy

Credential storage

BotPasswords are encrypted with AES-256 (Fernet symmetric encryption) before being written to the database. The encryption key is stored only as a Toolforge environment variable — never in source code, never in the database, never in the repository. The plaintext password is decrypted only at the moment of publishing, held only in local memory for that one operation, and immediately overwritten when the function returns. It is never logged, never returned in an HTTP response, and never written to any storage.

Session isolation

Each publish uses a fresh HTTP session with no shared state between users or requests. Publishing uses the MediaWiki Action API directly — the same underlying calls that pywikibot makes — via Python's requests.Session. One publish runs at a time per user account, enforced by a database mutex. A five-minute stale-task cleanup prevents permanent lockout in the event of an unexpected server restart.

Minimum permissions model

The tool guides users to create BotPasswords with only the permissions required for their use case. It explicitly advises against granting sitewide JS/CSS editing rights. The tool itself holds no sitewide editing permissions — every edit made through WikiScriptSync is made under the user's own account with the permissions that user explicitly granted.

What is stored

WikiScriptSync stores: Wikimedia username, repository URLs, file paths, destination wiki and page names, notification history, and publish audit logs. File content is never stored. OAuth tokens are session-only and not persisted. BotPasswords are stored encrypted and never returned to the client.

Limitations

Only public GitHub and GitLab repositories are supported for monitoring.
Only .js and .css files are tracked in repository monitoring.
Repository checks run hourly; wiki page checks run every 30 minutes.
Talk-page notifications are delivered on Meta-Wiki only.
Publishing requires the user to set up their own BotPassword on each target wiki.
The tool uses a shared GitHub API token for repository checks. Above approximately 100 monitored repositories across all users, some checks may be deferred.

Operational status

Component	Status	Detail
Repository monitoring	Active	Hourly SHA checks
Wiki page monitoring	Active	30-minute revision ID checks
Bot publishing	Active	Manual, preview-first
Daily log cleanup	Active	Runs at 03:00 UTC
WikiScriptSyncBot	Active	Posts notifications on meta.wikimedia.org

Development history

WikiScriptSync emerged from the 2022 Community Wishlist Survey proposal submitted by Nux. An initial prototype built in Node.js and Next.js was shared with Nux in October 2025 and received detailed feedback covering multi-target publishing, dev/release profiles, safeguard requirements, and the importance of Toolforge deployment.

Based on that feedback and technical guidance during the Developer Skill Development Program India 2025, the project was rebuilt in Python and Django for Toolforge compatibility. OAuth registration and a security review led to the current design, which limits OAuth use to identity verification only, and implements publishing through user-controlled BotPassword credentials.

Version 1.1 (May 2026) added wiki page monitoring (following feedback from Felipe Schenone on wikitech-l) and the BotPassword publishing module (following architectural guidance from Nux).

The project is grateful for the sustained guidance of KCVelaga (WMF) throughout the development and programme period.

Community discussion

User talk:Dev Jadiya#Script Publisher — Security and scope discussion with Tgr (WMF), Nux, and KCVelaga (WMF)
Community Wishlist Survey 2022/Bots and gadgets/A bot or gadget to publish public Git repo to a gadget or user script — Original proposal by Nux
Steward requests/Miscellaneous#OAuth permissions — OAuth review request and outcome

Source code and contributions

Source code: https://gitlab.wikimedia.org/toolforge-repos/script-publisher

Licence: MIT License

Bug reports and feature requests: User talk:Dev Jadiya or the GitLab issue tracker.