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 theDocumentation 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.
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.orgBeta realm wikis
Database name:
{name}wikibetaServed on {name}.betaoasis.xyzMirahezeFunctions::SUFFIXES:
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 fromLocalSettings.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 inwgCreateWikiCannedResponses. 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
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.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.
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.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).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.Missing Wiki Handling
If a request arrives for a hostname that does not match any entry incw_cache/databases.php, MirahezeFunctions::isMissing() returns true. The farm then checks the host:
- For
*.skywiki.orghosts:MissingSkyWiki.phpis served, directing bureaucrats to emailstewards@wikioasis.orgfor migration assistance. - For all other hosts:
MissingWiki.phpis 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 (currently1.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.