Wikimedia site requests

From Wikitech
Jump to navigation Jump to search

Wikimedia site requests are requests to configure a Wikimedia project. This page gives an overview of the process for volunteers handling them, and other concerned parties from operations side.

If you do not want to contribute technically, follow meta:Requesting wiki configuration changes instead.

If you want to contribute technically, then this is a good way to get familiar and start contributing to software changes. You need very basic knowledge of PHP and follow mw:Gerrit/Tutorial to create your first software change (a so-called "patch"). When you work on these types of tasks you can also look at previous similar software changes. Often you do not even have to have too much understanding of what is going on exactly. But still you can get familiar with code and especially processes!

Lifecycle of a request

A request generally follows this workflow:

  1. The local project discusses the matter in public, in the manner the most appropriated for this project.
  2. A task is filed on Phabricator, in the Wikimedia-Site-requests project (or Wikimedia-Extension-setup if the change is about enabling an extension). See meta:Requesting wiki configuration changes. Please check Limits to configuration changes before.
  3. A volunteer writes a software change (patch) to change the relevant files in the operations/mediawiki-config code repository, as we do not directly edit the code that is running live on the servers. Then the volunteer proposes this patch in Gerrit for review. (If the volunteers follow Gerrit/Commit message guidelines, then the Phabricator task will automatically get updated about their patch in Gerrit.)
  4. Another pair of eyes will review this patch in Gerrit.
  5. If no reviewer sees a problem with the patch, then the same volunteer - or if reluctant/absent/busy, another volunteer - schedules it in a backport window on the Deployments page.
  6. In that backport window, the software change (patch) is merged via a deployer giving it a "Code-Review +2" review and deployed on the Wikimedia servers, usually within one week but sometimes also faster. Only after this step has happened, everybody who visits a Wikimedia server will see / experience that change.


Requests are usually handled quickly. We can deploy (make the changes available on the servers) trivial changes three times per day between Monday and Thursday.

Priority on Phabricator Description
Unbreak now! The change fixes a problem that must be fixed immediately. You want a deployment right now or in the next hours. That also means you think that your request is more important and urgent than any other requests.
High The change is needed very soon, ideally in the next backport window, or if not possible, this week (Monday-Thursday).
Medium The change is helpful, we can do it this week or the next (so in max. 7-10 days). This is the priority assigned to most simple tasks.
Low The change isn't needed before two weeks or there is nothing actionable before a long time.

Common tasks

Disable throttling of account creations for an IP at events

Often requested by editors who are hosting an edit-a-thon, account creation throttle exception are one of the most common tasks which Wikimedia site requests deals with. Such requests should follow meta:Mass account creation#Requesting temporary lift of IP cap.

  • Make your changes in the file wmf-config/throttle.php in the repository operations/mediawiki-config
    • from UTC date/time of exception start
    • to UTC date/time of exception end
    • range IP range(s) the exception applies to
    • dbname wiki(s) this exception applies to
$wmgThrottlingExceptions[] = [ // T184579
	'from' => '2018-01-11T09:00 +5:30',
	'to' => '2018-01-11T18:00 +5:30',
	'range' => [ '', '' ],
	'dbname' => [ 'enwiki', 'mrwiki' ],
	'value' => 45 // 35 expected

If there is less than 72 hours before the event, you should run mwscript resetAuthenticationThrottle.php --wiki=metawiki --signup --ip to purge the memcached key.

See Increasing account creation threshold.

Change the translation of a namespace

  • Namespace localization must happen in the extension that the namespace belongs to.
  • Namespace localization can require separate patches in some repositories. See e.g.
  • To deploy a custom namespace only on Wikimedia sites (and not in the MediaWiki software for everybody), the file to change is wmf-config/core-Namespaces.php in the repository operations/mediawiki-config. This file also allows you to change project namespace (wgMetaNamespace).

Change the linktrail

Update the interwiki cache

Change local group rights

  • Change/define the group's right under GroupOverrides in the file wmf-config/core-Permissions.php in the repository operations/mediawiki-config
  • Change who can grant the group using (Add|Remove)Groups(Self), otherwise, only the stewards will be able to grant/remove it.

Change user groups and restriction levels

Enable or disable extensions on a wiki

Change import sources

Add a website to CopyUploadsDomains (e.g. for GWToolset)

Convert digits (numbers) into a different script

Remove a namespace from being indexed by internet search engines

Change the default timezone for a wiki

Add additional letters to the special characters toolbar

Add a wiki to a dblist

See Configuration files#dblists.

Areas in the MediaWiki code base itself

These tasks are about the general MediaWiki code base itself, and not about the configuration of MediaWiki on Wikimedia servers like the tasks above.

Replacing deprecated functions

These functions could be found by phan checks or a good IDE with static analytic code checks.

Upgrading dev libraries

This is sometimes done by a bot, but that is not always and not everywhere the case.

Alphabetize stuff

Common tasks that need a maintenance script

This section is meant to document site requests that require a maintenance script to be executed shortly after deploying the patch, to ensure the configuration change takes the intended effect. See also Backport windows/Deployers#Maintenance_scripts.

Add a custom namespace

  • Add the new namespace under wgExtraNamespaces in the file wmf-config/core-Namespaces.php in the repository operations/mediawiki-config. In the namespace name, make sure to replace spaces ( ) with underscores (_).
  • Past examples: phab:T221697 and
  • Script: After the change has been deployed (merged), run namespaceDupes.php to ensure no page will be left unaccessible.

See also: mw:Manual:Using custom namespaces

Change a namespace

  • Make your changes in the file wmf-config/core-Namespaces.php in the repository operations/mediawiki-config
  • If necessary, also alias old names under wgNamespaceAliases in the file wmf-config/InitialiseSettings.php in the repository operations/mediawiki-config
  • Past example: phab:T202347 and
  • Script: After config change is deployed, run namespaceDupes.php maintenance script to no page will be left unaccessible.

Change category collation

  • Make your changes in the file wmf-config/InitialiseSettings.php (under wgCategoryCollation) in the repository operations/mediawiki-config
  • Past example: and phab:T329815.
  • Script: After config change, run mwscript updateCollation.php --wiki=xxwiki --previous-collation=uppercase to ensure the change takes effect.
    • NOTE: In most cases, the previous collation is uppercase, but double check that before running the script.

Change the logo of a Wikimedia wiki

Please follow the instructions in the logos directory of operations/mediawiki-config for converting a Commons SVG into the correctly compressed PNGs and updating the PHP files.

Read meta:Logo, especially the Temporary logo variants section.

You can test how a new logo will look at (replace and FilenameOnCommonsOfTheNewLogo.svg accordingly)

Past examples:,,

Script: Run echo '' | mwscript purgeList.php (the domain is always, even for other wikis). The command needs to be executed for each HD version (-1.5x.png and -2x.png suffixes), or any other file changed in the /static folder. See also Backport windows/Deployers#Purging.

Useful links