You are browsing a read-only backup copy of Wikitech. The live site can be found at wikitech.wikimedia.org
Add a wiki: Difference between revisions
imported>Ebernhardson (→Search) |
imported>Urbanecm m (→Search: typo #2) |
||
Line 204: | Line 204: | ||
<syntaxhighlight lang="shell-session"> | <syntaxhighlight lang="shell-session"> | ||
$ mwscript extensions/CirrusSearch/ | $ mwscript extensions/CirrusSearch/maintenance/UpdateSearchIndexConfig.php --wiki=$wiki --cluster=all | ||
</syntaxhighlight> | </syntaxhighlight> | ||
Revision as of 15:53, 19 October 2020
![]() | This guide may be incomplete. Some cases don't need Apache configs or a docroot. Look at the existing similar wikis to see what is required. |
This page documents the process for adding a new wiki. This includes new languages on sister projects, and wikis for committees, chapters etc.
Preparation
The following steps need to be completed before the wiki database may be created.
Notify
- Create a Phabricator task for the wiki creation (if one doesn't exist already).
- It should be tagged with
#Wiki-Setup (Create)
.
- It should be tagged with
- Create (if not already) a sub-task "Prepare and check storage layer for <new wiki>".
- It should be tagged with
#DBA
,#wmcs-kanban
and#Data-Services
.
- It should be tagged with
- Notify the Operations list. In particular, it needs to be made clear whether the wiki should be public, or private. If public, ops will arrange for the wiki to be replicated to Cloud Services. If private, ops will need to add the wiki to
$private_wikis
inoperations/puppet.git:/manifests/realm.pp
. - IMPORTANT: If the wiki is a regular public wiki to appear on Cloud Services - you can continue. If the wiki is private and should not be replicated to Cloud Services DO NOT CONTINUE UNTIL YOU HAVE THE OK FROM OPS/DBAs to check no private data is leaked. There are mechanisms in place to prevent that by default, but those should be manually checked.
DNS
First of all, ensure the relevant domain names exist for the new wiki. Make the following changes in a commit for the operations/dns.git repo and submit to Gerrit for review.
- If it is a language project, ensure the language code is present in
/templates/helpers/langlist.tmpl
. This is shared between all sister projects. If another sister project has the same language already, then this has probably been done already. - If it is a subdomain of ".wikimedia.org" domain (chapter wiki or special wiki)
- Add it to
/templates/wikimedia.org
. - Make sure to also add a mobile entry.
- Add it to
- Merge the change in Gerrit and run
authdns-update
. - Query the DNS servers to make sure it has been correctly deployed. See DNS#HOWTO for details.
- For new languages, there is also a need to regenerate zones. Run on ns0, ns1 and ns2:
authdns-gen-zones -f /srv/authdns/git/templates /etc/gdnsd/zones && gdnsdctl reload-zones
Apache configuration
Apache configuration is located in the operations/puppet.git repo.
- Common configuration:
- For a new language project, this step is usually not needed as shared configuration already covers it.
- For a new chapter wiki, add it to
::mediawiki:web::prod_sites
underwikimedia-chapter
- After the change is merged in Gerrit, deploy the configuration change and (if needed) gracefully restart app servers. See Application_servers/Runbook#Deploying_config for details.
- If there are additional domains that should point to the same wiki, add it to
redirects/redirects.dat
.
Language configuration
Check the following for every wiki, even if another wiki in this language already exists:
- Make sure that the wiki's content language code appears in the language-data repository (file data/langdb.yaml).
- Make sure that the wiki's content language code is fully configured to be supported by core MediaWiki. It must appear in languages/data/Names.php and it must have an associated languages/messages/MessagesAbc.php file (replace Abc with the language code).
- Check that usernames in the writing system of this language are possible and aren't filtered out. If they are, add support for this writing system to AntiSpoof. Example patch.
- If the language is written from right to left, make sure it appears in the following files:
- In the MobileFrontend extension repository: src/mobile.languages.structured/rtlLanguages.js
- In the Android app repository: app/src/main/java/org/wikipedia/util/L10nUtil.java (the RTL_LANGS list)
- In the iOS app repository: Wikipedia/Code/MWLanguageInfo.m (the rtlLanguages list)
Determine if this is a new language project (like Spanish Wikibooks) or a chapter wiki (like Wikimedia Denmark), or something else (special wiki or private wiki).
For a new language project, make sure the language has been approved by the Language committee at Requests for new languages on Meta-Wiki. Usually, the Phabricator task will contain a link to the approval page. follow the steps below. For all other wikis, go directly to #Install.
Install
IMPORTANT: For Private Wikis
- Private wiki databases must not be replicated to the Cloud Services DB MySQL instances!
- Before creating a database for a private wiki, make sure to add the db name to the puppet global array
$private_wikis
inoperations/puppet.git:/manifests/realm.pp
. - Deploy this config change with puppet and manually restart the
Prelabsdb-db
MySQL instance (Sanitarium) on the server that will house this wiki's db (most likelys5
). - If you need help with this, please ask a member of the Ops team for help. This is very important.
- Before creating a database for a private wiki, make sure to add the db name to the puppet global array
MediaWiki configuration
Gather all relevant information about the new project. Each wiki has different requirements (project name, namespaces, extensions to be enabled etc).
Make the following changes on your own checkout of operations/mediawiki-config.git and submit to Gerrit for review:
- For a new language project, add the language code (ISO 639 code: usually provided in the task) to langlist. This will be used at Special:SiteMatrix and for interwiki linking etc.
- Create the YAML definition of the wiki in
wmf-config/config
, including making it inherit from relevant settings profiles, as follows:
Wiki grouping | Group options | Purpose |
---|---|---|
All
|
all.dblist | The primary listing of what wikis exist, used as the basis of all tools. |
DB cluster
|
s1.dblist s2.dblist s3.dblist s4.dblist s5.dblist s6.dblist s7.dblist s8.dblist s10.dblist s11.dblist |
Database lists of wikis in each MySQL database cluster. In most cases, wikis should just be added to s5 s10 was previously known as wikitech
|
Wiki size
|
small.dblist medium.dblist large.dblist |
Database lists of wikis arranged into their relevant size. |
Wiki family
|
wikimania.dblist
wikimedia.dblist wikibooks.dblist wikinews.dblist wikipedia.dblist wikiquote.dblist wikisource.dblist wikiversity.dblist wikivoyage.dblist wiktionary.dblist special.dblist |
Sister project, Wikimania, chapter, or special.
NOTE: Some wikis maybe in special and one other list. |
Closed | closed.dblist | Any closed (no write access, full read access) wikis |
Deleted | deleted.dblist | Wiki databases which MediaWiki is no longer configured to access |
Wiki privacy | fishbowl.dblist | All fishbowl (restricted write access, full read access) wikis |
private.dblist | All private (read and write restricted) wikis | |
Extension configurations | flaggedrevs.dblist | All wikis running the FlaggedRevs extension |
securepollglobal.dblist | $wgSecurePollCreateWikiGroups wikis: Board Election wikis | |
visualeditor-nondefault.dblist | All wikis where VisualEditor is not enabled by default | |
commonsuploads.dblist | All wikis which should have local uploading soft-disabled. Uploads go to Commons instead. | |
Wikidata-related wiki groups | wikidata.dblist | All wikis running the Wikidata repo |
wikidataclient.dblist | All wikis running the Wikidata client (most new language-project wikis should start off like this) |
- Once your YAML file is created, add a dummy entry to
wikiversions.json
mapping the database name to a version string, then runcomposer test
which will update the automatic "dblist" files and spot any issues. Alternatively, you can runcomposer buildDBLists
which only builds the dblists. - If the new wiki is created at a different shard than s3 (which is likely, as new wikis are created at s5 as of August 2020), you need to add the wiki to
wmf-config/db-eqiad.php
andwmf-config/db-codfw.php
. Check with DBAs if you're unsure how to properly edit the file, this is very important. - Update the configuration files (located in
/wmf-config
). Some may have sufficient defaults but the following are often wiki-specific in InitialiseSettings.php:- $wgServer, $wgCanonicalServer - For language projects, the defaults work fine.
- $wgLogos, $wgSitename, $wgExtraNamespaces, $wgLocaltimezone.
groupOverrides
.- Ensure $wgCategoryCollation is set to the appropiate sorting for this wiki's language. If you are not sure, ask on the task.
- If an extension needs to be enabled, this is usually done by setting a wmg-variable to true in InitialiseSettings along with custom configuration there. Some extensions' configuration are located in a dedicated files in the
/wmf-config
directory.
- If you added a new language code to the langlist (see above), you probably need to add it to the InterwikiSortingOrder.php file too
- For "*wikimedia" suffix databases, add the subdomain to the list in MWMultiVersion::setSiteInfoForWiki
- Adjust the entry in
wikiversions.json
to the current production version. See Deployments (one week) and Deployment Train.
Database creation
Once the above is reviewed, merged and pull down on the deployment host also pull it down on mwmaint1002 (scap pull), but do not yet deploy to main app servers until after the database is created.
Now it's time to actually create the database. The installation script also performs other tasks, such as notifying the "newprojects" mailing list. The installation script must be run from mwmaint1002 (not the deployment host). If the wiki is going to be a Wikidata client, make sure it's present in the wikidataclient.dblist
file and that the new version of that file has been pulled down on mwmaint1002 **before** running the installation script, or things will break.
The dummy wiki (noted as muswiki
in the code) is shard-dependant. Wikis at s5
should be created using muswiki
, while wikis at s3
were created via aawiki
. Wiktionaries needs to be created via mhwiktionary
(s5) and aawiktionary
(s3).
The syntax is as follows:
mwscript extensions/WikimediaMaintenance/addWiki.php --wiki=muswiki <languagecode> <projectname> <databasename> <domain>
- For a new Wikipedia - for example Lingua Franca Nova Wikipedia:
mwscript extensions/WikimediaMaintenance/addWiki.php --wiki=muswiki lfn wikipedia lfnwiki lfn.wikipedia.org
- For another new language projects - for example a Spanish Wikinews:
mwscript extensions/WikimediaMaintenance/addWiki.php --wiki=muswiki es wikinews eswikinews es.wikinews.org
- For a new chapters wikis - for example a Finnish chapter wiki:
mwscript extensions/WikimediaMaintenance/addWiki.php --wiki=muswiki fi wikimedia fiwikimedia fi.wikimedia.org
- For non-standard special wikis (such as committees, or unique projects like meta or commons) - for example strategy.wikimedia.org:
mwscript extensions/WikimediaMaintenance/addWiki.php --wiki=muswiki en wikimedia strategywiki strategy.wikimedia.org
- Merge the config change in Gerrit, and pull it onto deploy1001.
- Verify that the *.dblist files now contain the new wiki.
- Pull the whole on mwdebug1002 and mwmaint1002 through
scap pull
- Run the addWiki maintenance script, as described above (important to do before any sync of dblists or wikiversions, as some components like login use that)
- Run
scap sync-file dblists
to synchronize all database lists - Verify wikiversions.json is sane.
- Run
scap sync-wikiversions
to synchronize the version number to use for this wiki - Run
scap sync-file multiversion/MWMultiVersion.php
when needed, ie if you add a new *.wikimedia.org site - Run
scap sync-file wmf-config/InitialiseSettings.php
- Run
scap sync-file static/images/project-logos/
- If adding a new language code, run
scap sync-file langlist
(this must be done before deploying the updated interwiki cache - step 13) - Unless it's a language project, add the project to the meta:Interwiki map.
- Regenerate the interwiki cache and deploy it. (For all new wikis, not just new language projects.)
scap update-interwiki-cache
(and then follow the instructions)- Edit meta:Interwiki map and update when the last update was.
RESTBase
RESTBase is a service providing a RESTful API for the projects' wikis. To enable it to serve the new wiki as well, create a patch for mediawiki/services/restbase/deploy
adding its domain to the appropriate section in RESTBase's configuration. Add Ppchelko to review the patch, and wait for it to get merged, or create a task tagged with #platform-team
. This will then require a restart of the RB service across the cluster, which can be done by ops or restbase-admins/restbase-roots.
Parsoid
Parsoid is now integrated with core, and should pick up the wiki automatically.
cxserver
For project families in which the ContentTranslation is installed (as of 2018—only Wikipedia projects): Add the language code to the ContentTranslation registry - mediawiki/services/cxserver
repository, file config/languages.yaml
(included by config.dev.yaml and config.prod.yaml).
Once merged to master, ping the ContentTranslation developers to deploy the change. That requires to sync repositories, ie to update mediawiki/services/cxserver/deploy to match mediawiki/services/cxserver. See: https://gerrit.wikimedia.org/r/#/c/303763/ for an example commit.
Search
Search indices need to be initialized for new wikis starting with 1.36.0-wmf.10. For a typical wiki creation only the following command is necessary. See Search#Adding new wikis for more information.
$ mwscript extensions/CirrusSearch/maintenance/UpdateSearchIndexConfig.php --wiki=$wiki --cluster=all
Swift
Necessary changes are made automatically by the addWiki.php script.
Cloud Services
Ensure a DBA has created the ${wiki}_p
database and granted access to labsdbuser
(otherwise a bug in MariaDB will cause the scripts to fail). This what they will probably do:
$ sudo -i mysql --skip-ssl
mysql:root@localhost [(none)]> GRANT SELECT, SHOW VIEW ON `$wiki\_p`.* TO 'labsdbuser';
mysql:root@localhost [(none)]> FLUSH PRIVILEGES;
Once it is replicating to the labsdb* servers (e.g. labsdb1009, labsdb1010, labsdb1011 and labsdb1012), run the following 2 commands on each replica server:
localhost:~$ ssh labsdb10xx.eqiad.wmnet
labsdb10xx:~$ sudo /usr/local/sbin/maintain-replica-indexes --database $wiki --debug
labsdb10xx:~$ sudo /usr/local/sbin/maintain-views --databases $wiki --debug
Note the shard for use with the wikireplica dns next
labsdb10xx:~$ grep $wiki /usr/local/lib/mediawiki-config/dblists/s*.dblist* | grep -o '\w[0-9]'
:# Should return a shared, like s3, s5, etc
From a cloud control host, add the wikidb alias in the Wiki Replicas service name:
localhost:~$ ssh cloudcontrol1003.wikimedia.org
cloudcontrol1003:~$ sudo -i
cloudcontrol1003:~$ source novaenv.sh
cloudcontrol1003:~$ /usr/local/sbin/wmcs-wikireplica-dns --aliases --shard <sN>
:# Use the shard arg only if you know the shard (which you can get on a replica server as noted above)
:# If the shard is s3 or a full rebuild is done it will take quite a while to run
Insert a new row in meta_p.wiki
for the new wiki by running the following on each of the replica servers.
localhost:~$ ssh labsdb10xx.eqiad.wmnet
labsdb10xx:~$ sudo /usr/local/sbin/maintain-meta_p --database $wiki
Before resolving the ticket, log into a Toolforge bastion as yourself and run:
localhost:~$ ssh login.toolforge.org
tools-sgebastion-07:~$ sql $wiki
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 470351380
Server version: 10.1.43-MariaDB MariaDB Server
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [$wiki_p]> select * from page limit 2;
If you get an error from the select * from page limit 2;
statement, you may have missed a step or need to do some troubleshooting. You should just get a couple records.
WikimediaMessages
Translatable project name
Add a message with the wiki name to extensions/WikimediaMessages/i18n/wikimediaprojectnames/en.json
and qqq.json
. The message keys should include the wiki database name (WIKI_DBNAME
below) and official "human readable" name (WIKI_NAME
below) as follows:
Key | Message |
project-localized-name-WIKI_DBNAME
|
WIKI_NAME
|
For example, "project-localized-name-enwiki": "English Wikipedia",
Key | Message |
project-localized-name-WIKI_DBNAME
|
{{ProjectNameDocumentation|url=WIKI_URL|name=WIKI_NAME|language=WIKI_LANG}}
|
For example, "project-localized-name-enwiki": "{{ProjectNameDocumentation|url=https://en.wikipedia.org|name=English Wikipedia|language=en}}",
Cross-wiki (a.k.a. interwiki) search result title
If this is a new language Wikipedia, add a message with the wiki name to extensions/WikimediaMessages/i18n/wikimediainterwikisearchresults/en.json
and qqq.json
in the list of search-interwiki-results messages.
Wikipedia mobile apps
If you are creating a new Wikipedia, add an entry for the new language.
For the Android app, you must run the following two scripts, which will update the list of languages known to the app (including the corresponding language codes, autonyms, English names, etc.):
$ cd scripts $ ./generate_wiki_languages.py $ ./make-templates.py
This should update several .java
and .xml
files that you may then submit in a pull-request to our repository.
(TODO: Is there anything to do for the iOS app?)
Post-install
Wikidata
Only needed if the new wiki is supposed to be a Wikidata client.
In order to be able to link the new wiki from Wikidata, and to allow interwiki links from Wikidata to the new wiki, run extensions/Wikibase/lib/maintenance/populateSitesTable.php --force-protocol https
on at least all Wikidata clients (including wikidatawiki itself and testwikidata).
foreachwikiindblist wikidataclient extensions/Wikibase/lib/maintenance/populateSitesTable.php --force-protocol https
That script is known to be troublesome, you might want to ask Marius (hoo) or Amir Sarabadani (Amir1) run it for you or just create a ticket (that may be done anytime after the wiki was created).
Beware: The script sometimes fails with a duplicate key conflict. In that case, go to the wiki's master database and empty the sites and site_identifiers tables, then run the script again. It's probably also wise to backup these tables from Wikidata and at least one Wikipedia before running the script across the whole fleet. Breaking the sites, site_identifiers tables will break page rendering of many wikis!
Analytics
If the wiki is not private, not a Wikimania conference wiki, and not special wiki like usability/outreach/login/vote/strategy/etc., send a change proposal to analytics/refinery.git
that adds the wiki to static_data/pageview/whitelist/whitelist.tsv
If pageviews to the wiki need to be included in the pageview definition, check the code or ask the Analytics team. The code for definition and regular expressions used to include or exclude domains as official pageviews.
Incubator
If there's something to import (as is often the case in new language projects), someone will do so. Their process is described at Incubator:Importing from Incubator (logged at Incubator:Site creation log).
Clean up interwiki links
After any import Incubator is completed, Inform the community and make a Phabricator task for removing old interwiki links and migrating them to Wikidata (For example T134991 for edits such as d:Special:Diff/336584053 and jam:Special:Diff/12330). You can do it by yourself using interwikidata.py in pywikibot.
python pwb.py scripts/interwikidata.py -lang:LANGCODE -clean -start:! -always
Tell wikistats Cloud VPS project to add the wiki
If the wiki is a public wiki, create a Phabricator task (subtask of the main task to create the wiki) with the tag "VPS-project-wikistats" and just ask for the wiki to be added. (What needs to be done can be seen f.e. in https://phabricator.wikimedia.org/T140970#2531977)
Tell Pywikibot project to add the wiki
Create a Phabricator task (subtask of the main task to create the wiki) with the tag "pywikibot" and just ask for the wiki to be added.
Mobile apps
Wikipedia has mobile apps for Android and iOS. A Wikipedia in a new language must work in the app after the import from the Incubator is complete. Report a bug under the apps tags in Phabricator if any of the following doesn't work:
- You are supposed see the language in the user preferences.
- Android: Settings -> Wikipedia language.
- iOS: Settings -> My languages
- You see the language in the interlanguage links list. Find an article that exists in the new Wikipedia and in English. Go to the English Wikipedia, tap the 文Α icon at the bottom and find the article in the list. In particular:
- The article name must appear.
- The language name (autonym) must appear.
- The item must be findable using the language name in English and the autonym. (If you don't know how to type the autonym, try pasting the autonym or ask somebody who writes in that Wikipedia.)
- Tapping the item must show the article.