Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/wikioasis/mw-config/llms.txt

Use this file to discover all available pages before exploring further.

Every wiki on WikiOasis begins life as a formal request. The CreateWiki extension powers this workflow end-to-end: a user submits Special:RequestWiki on meta.wikioasis.org, a steward or global-sysop reviews the request against the Content Policy, and — on approval — CreateWiki provisions the database, writes initial SQL tables, and registers the new wiki in the cw_cache/databases.php cache file that MirahezeFunctions reads on every web request. From that moment forward, any HTTP request targeting the new subdomain is routed correctly without any server-side deployment step.

Database Naming Convention

WikiOasis uses a strict suffix-based naming scheme so the farm can determine a wiki’s realm purely from its database name.

Production wikis

Database name: {name}wikiServed on {name}.wikioasis.org and {name}.skywiki.org

Beta realm wikis

Database name: {name}wikibetaServed on {name}.betaoasis.xyz
The two suffix keys are defined in MirahezeFunctions::SUFFIXES:
public const SUFFIXES = [
    'wiki'     => ['wikioasis.org', 'skywiki.org'],
    'wikibeta' => ['betaoasis.xyz'],
];
MirahezeFunctions::getCurrentDatabase() resolves an incoming hostname to its database name by stripping the known domain and appending the matching suffix. If the resolved suffix does not match the expected realm for the current server, the request is intercepted before MediaWiki fully loads.

CreateWiki Configuration

The following settings from LocalSettings.php govern how wiki requests are processed on WikiOasis:

Subdomain root

wgCreateWikiSubdomain is set to wikioasis.org, making that the canonical subdomain namespace for all new wikis.

Database suffix

wgCreateWikiDatabaseSuffix is wiki, so every provisioned database is appended with wiki automatically.

Job queue provisioning

wgCreateWikiUseJobQueue is true — wiki creation is processed asynchronously through the MediaWiki job queue for reliability.

State management

Inactive, closed, and private wikis are all enabled via wgCreateWikiUseInactiveWikis, wgCreateWikiUseClosedWikis, and wgCreateWikiUsePrivateWikis.

Canned Responses

Stewards selecting outcomes in the request review UI can choose from pre-configured canned responses defined in wgCreateWikiCannedResponses. These prevent inconsistent phrasing and ensure policy references are accurate.

Approval

A single approval message reminding wiki creators to comply with the WikiOasis Content Policy at all times.

Decline reasons

Pre-written declines covering: obscene subdomain, vandalism/trolling, and eight distinct Content Policy provisions (illegal content, hate speech, gratuitous NSFW, commercial promotion, file hosting, anarchy wikis, duplicate scope, and problematic content).

On-hold reasons

Three hold reasons: requesting more detail, awaiting a user response, and pending internal steward review.

Disallowed Subdomains

wgCreateWikiDisallowedSubdomains prevents certain reserved names from being registered. The blocked list includes: www, ftp, mail, webmail, admin, administrator, hostmaster, webmaster, abuse, contact, info, privacy, legal, help, support, blog, wiki, wiki2, forums, forum, phorge, phabricator, phab, issues, bugzilla, and issue-tracker.

From Request to Live: Step by Step

1

Submit Special:RequestWiki

A logged-in user on meta.wikioasis.org fills in the wiki request form — providing a subdomain, sitename, description, language, and category. The request requires the requestwiki right, which is granted to all registered users on metawiki.
2

Steward reviews the request

A steward or global-sysop evaluates the request against the WikiOasis Content Policy. They may place the request on hold pending clarification, decline it with a canned response, or approve it.
3

CreateWiki provisions the database

On approval, CreateWiki asynchronously creates the MySQL database ({name}wiki), runs the SQL table set defined in wgCreateWikiSQLFiles, and sets up the initial S3 storage containers for the wiki’s media.
4

Cache is written to cw_cache/databases.php

CreateWikiDataStore->syncCache() writes the new wiki’s entry — including sitename (s), cluster (c), primary domain (d), and MediaWiki version (v) — into cw_cache/databases.php at CACHE_DIRECTORY (/srv/mediawiki/cw_cache).
5

MirahezeFunctions picks up the wiki

On the next HTTP request to the new subdomain, MirahezeFunctions::getLocalDatabases() reads cw_cache/databases.php. The new database name is now in $wgConf->wikis, so isMissing() returns false and the wiki loads normally.
6

Wiki is live

The wiki is fully accessible. The requesting user is automatically made a bureaucrat and can begin configuring extensions, permissions, and settings via Special:ManageWiki.

Missing Wiki Handling

If a request arrives for a hostname that does not match any entry in cw_cache/databases.php, MirahezeFunctions::isMissing() returns true. The farm then checks the host:
  • For *.skywiki.org hosts: MissingSkyWiki.php is served, directing bureaucrats to email stewards@wikioasis.org for migration assistance.
  • For all other hosts: MissingWiki.php is served — an HTTP 410 Gone page with WikiOasis branding and links to meta.wikioasis.org and the Discord.
After serving the 410 page, MissingWiki.php calls CreateWikiDataStore->syncCache() to refresh the cache. This means a legitimately created wiki that appears “missing” due to a stale cache will automatically self-heal on the next request — no manual cache purge is required.

Version Pinning at Creation

By default, every new wiki runs on the farm’s stable MediaWiki version (currently 1.45). Version overrides are stored in wikiVersions.php and require the managewiki-restricted right to change.
Only stewards and tech team members hold the managewiki-restricted right. Regular wiki bureaucrats cannot change a wiki’s MediaWiki version. See Per-Wiki Version Management for full details.

Build docs developers (and LLMs) love