Rename a wiki

Domain rename draft (2015)

TODO: Refactor this page to three parts - what to do to prepare; what to do at the execution (deployment); what to do after deployment (including testing.)

This page deals with moving a wiki from one domain to another.

1. Deal with site language rename if relevant (i.e. probably not for a special wiki)
   • Make sure that Names.php, Messages*.php and */i18n/*.json in core have the new names and codes.
   • Make sure that langdb.yaml in UniversalLanguageSelector has new names and codes and redirects from the old names. (For als -> gsw there's also an extra redirection in UniversalLanguageSelector, so remove it when needed.)
2. Add new wiki domain to DNS zone (operations/dns.git)
3. Update operations/puppet.git
   • Update/add apache config (operations/puppet.git modules/mediawiki/files/apache/sites) to send new domain to MediaWiki (wikimedia.org subdomains etc. Normal project domains should already be covered by a wildcard)
   • Add new domain to RESTbase config (operations/puppet.git modules/restbase/templates/config.yaml.erb)
4. MediaWiki config (operations/mediawiki-config.git) to make new domain work as an alias:
   • Map new wiki domain to database name (multiversion/MWMultiVersion.php, setSiteInfoForWiki function)
     • If the database suffix was not 'wiki', the site code will not be 'wikipedia' so make sure that gets changed too (see ee.wikimedia.org as an example)
   • If moving a wiki from the wrong ISO code, also move the wgLanguageCode entry in wmf-config/InitialiseSettings.php up
5. You may have to purge some pages from Varnish (action=purge or SquidUpdate::purge) if they were used for testing the domain name before the mediawiki-config change went through, before you start seeing sane redirect behaviour for the new domain.
6. If WikimediaMaintenance's dumpInterwiki script had an alias in reverse of the rename, remove it like 236929, deploy commit and run updateinterwikicache on the deployment master host
7. TODO: Populate sites table (cache?) from wikidata (see task T111822)
8. Change MediaWiki config again to set wgServer/wgCanonicalServer to new domain, update the langlist file if relevant (for SiteMatrix - see task T111876)
   • If renaming a special site you may wish to deal with wgSiteName, wgMetaNamespace, etc. at this point
     • Changing namespace names requires an alias for the old name.
9. Update copy of the site matrix at mediawiki/services/parsoid.git lib/sitematrix.json so that v2+ APIs works on the new domain (v1 used database names) like 236831
10. Update MassMessage delivery lists on meta to use the new domain (see task T111895)
11. Another operations/puppet.git update
    • Add entry redirecting from old domain to new domain to operations/puppet.git modules/mediawiki/files/apache/sites/redirects/redirects.dat, run refreshDomainRedirects and submit result to gerrit
    • Remove old domain from RESTBase config
      • TODO: Work out with RESTBase devs what should actually happen. Note that currently /api/rest_v1/ on our domains does not follow Apache redirects.
12. ContentTranslation:
    • Remove the unnecessary redirection from SiteMapper - the ContentTranslationDomainCodeMapping global variable in extension.json. (like 236795)
    • After the migration, test that publishing to the new domain language works. (e.g. task T111818)
    • After the migration, test that loading a source article from the new domain works. (e.g. task T111850)
    • After the migration, test that link and category adaptation work (e.g. task T112285)
13. Eliminate existing interwiki links that point to the old domain, and make sure that href points to the new domain
    • For language-projects this is likely to be via dumpInterwiki.php in WikimediaMaintenance (like task T111853)
    • For special wikis it's likely to be at Interwiki map
14. Test that the langlinks API query works. (like task T112426)
15. If needed, rename the relevant messages and message keys in the following message files:
    • WikimediaMessages/i18n/wikimediaprojectnames
    • WikimediaMessages/i18n/interwikisearchresults
16. If needed, update $MassMessageWikiAliases with a map from the old to the new domain so that delivery lists keep working.

Database rename draft (2011)

Assumptions

• The language code of a wiki shall be renamed. The wiki keeps its "class" (e.g. wikipedia, wikiversity, etc).
• The languagecodes "old" and "new" will be used to name the old and new wikis. "newwiki" and "oldwiki" are the names of the new and old databases.

Approach

1. Add the new language code and the language name to languages/Names.php
2. Create messages/MessagesNew.php and, if necessary, classes/LanguageNew.php
3. Add the language code to /home/wikipedia/common/langlist
4. Set oldwiki to read-only
5. Create a mysql dump of the database oldwiki
6. Create a mysql dump of the extstores. Very old wikis will have text records stored in different extstores!
7. php maintenance/addwiki.php --wiki=oldwiki new newwiki newwiki new.wikipedia.org
8. Set newwiki to read-only
9. Import the database dump of the old wiki into the new database.
10. Import the extstore dump into the new exstore database.
11. Change all settings in InitialiseSettings.php and, if necessary, in flaggedrevs.php etc pp
12. Move the images from /mnt/upload6/project/old to /mnt/upload6/project/new and from /mnt/thumbs/project/old to /mnt/thumbs/project/new
13. ??? Do we have to do any changes for SUL?
14. Update the interwiki cache: php maintenance/dumpInterwiki.php -o cache/interwiki.cdb
15. sync-common-all
16. Add the new wiki in the DNS zone
17. Set newwiki to read-write
18. Set up redirects from old.project.org to new.project.org in /home/wikipedia/conf/redirects.conf
19. If no other wikis with language code old exist, remove old from /home/wikipedia/common/langlist
20. Remove oldwiki from all *.dblist files

open topics

1. update Lucene search system
2. clean page caches for all projects since the interwiki is incorrect in Squid caches (redirection can handle it though)
3. need a script to verify the configuration before and after (compare $_GLOBALS ? ), or use if( $wgDbName == 'oldwiki' || $wgDbName == 'newiki' )
4. synchronize the operation with toolserver. We might want them to do the same operation.
5. make sure search engines handle the redirection correctly (they should forget about the old page maybe 301 Moved Permanently).
6. this procedure should be fully tested
7. write a backup plan so we can easily apply it if anything goes wrong.
8. optionally clear memcached obsoletes keys