This task is part of the Wikimedia Foundation department's OKR (Objectives and Key Results) work. It is connected to the Future of Language Incubation, a new experiment to implement and test recommendations to support language incubation. This specific task is related to Automate Backend Site Creation recommendation.
Hypothesis statement: If we move addwiki.php to MediaWiki Core and customize it to Wikimedia, we will improve code quality in our wiki creation system making it testable and robust, and we will make it easy for creators of new wikis and thereby make significant steps towards simplifying wiki creation process.
addWiki.php in WikimediaMaintenance often breaks because it has its own list of extension table SQL files which need to be kept up to date, duplicating the LoadExtensionSchemaUpdates hook which is used everywhere except Wikimedia production.
The essential function of addWiki.php is not really specific to Wikimedia. It uses the configuration of an existing wiki as a bootstrap to create a new wiki. That's something which would be useful to non-WMF users.
A common criticism of addWiki.php is that it's not testable outside of production. By making it be more generic, we can test it in typical local installs.
So I propose moving addWiki.php to core and using a wrapper or hooks or both to customise it for Wikimedia.
T222913 asks for better staging/checkpointing features. So I imagine any hooks would define tasks to run, rather than actually doing the tasks. Then addWiki.php can provide features to:
- Create a checkpoint and restart from a given checkpoint
- Skip a stage
- Run a single stage
We don't currently run the updater in WMF production at all, because it's scary when you don't know exactly what it's going to do. But it should be less scary to run part of it on a new wiki. Maybe we can have some sort of dry run mode.
Task list
addWiki.php performs the following tasks:
- Environment checks (language existence, check extensions loaded)
- Core database and tables.
- Extension tables (equivalent to LoadExtensionSchemaUpdates). Instead of checking the site name to figure out the extensions, we would rely on the bootstrap wiki having the correct list of extensions, which could be confirmed with an environment check hook. Selecting a bootstrap wiki could be simplified using a wrapper script.
- site_stats (equivalent to core Installer::populateSiteStats).
- External store initialisation (core blobs, growth, echo, mediamoderation). This would be moved to hooks in the relevant extensions.
- Main page. This override could be in a file specified in configuration.
- Create Mediawiki:Sitesupport-url. Unclear why this is here and not in a hook in WikimediaMessages to override the default. Updating the URL would be a nuisance when it's overridden in this way.
- Wikibase populateSitesTable.php. We pass the "site group name", but SitesBuilder can also guess the site name with its WMF-specific hacks.
- Cognate populateCognateSites.php requires the "site group".
- setZoneAccess.php with backend and private option
- Refresh MassMessage urltodb cache
- Send notification to newprojects mailing list