Fallen London Wiki:How to leave Fandom

This wiki was able to relatively successfully move away from Fandom onto a self-hosted MediaWiki instance. I'd like to document what steps we took, in hopes that it might help other wikis who might wish to move, in future.

Considerations

One of the primary reasons our move was able to be so successful is because we had support from the company whose property this wiki documents. They provided support by signal boosting our announcement to every player of the game. This, combined with the fact that new content is continuously being released and the fact that we were able to ensure that said new content is only available on this wiki, has helped greatly with the move.

Additionally, the way in which our wiki is structured is relatively unique. Instead of standard articles, our wiki merely precisely documents in-game items and options. To that end, we make extensive - if not exclusive - use of templates. While this does produce a steep learning curve for would-be editors, it does make the task of avoiding information leakage onto Fandom easier, as there basically exist no editors who would know how to add content to the wiki and would not have seen our announcements.

If your target wiki is for a property:

• that does not receive many updates
• whose reading population is decentralized
• for which there is a low barrier to entry for editing
• for which you cannot obtain support from the organisation for whose property your wiki covers

you may have a much more difficult time diverting traffic from Fandom. Failbetter Games has two other properties - Sunless Sea and Sunless Skies - for which we would almost certainly have less success moving. Both games are nearly finished and are unlikely to receive further updates, the reading population is not centralized (both games are on multiple platforms, as opposed to Fallen London, which is solely a browser game), and the article format for said wikis is much less complex than for this wiki.

If, having understood the caveats, you still wish to proceed, read on.

Beginning steps

One of the first steps we took was establishing a centralised platform on which to collaborate. We used Discord for this, but any convenient platform would suffice. After this, we began outreach to active editors and key persons (sysops) on the Fandom wiki, informing them of our desire to move, and gauging amenability. Pointing out pain points with Fandom, and offering a vision of a self-hosted alternative, may help persuade. Many of the reasons on this page will likely be applicable to your situation.

After swaying a critical mass of editors and sysops, we reached out to Failbetter Games explaining our intentions and asking for support. A copy of the email can be found here. After some back-and-forth, they assented to providing funding for hosting, as well as support with publicising our move.

Technical details

The technical details of the move are something of which I have eminent knowledge.

For hosting, we're using virtual private servers from a cloud provider, running Linux. The technical advice in this section will be of less use for persons uncomfortable with self-hosting an instance of MediaWiki or with limited knowledge of how to work with servers directly (e.g., persons who may hope to use the services of a wiki farm, or who may seek to have a hosting provider set up MediaWiki without being able to access the shell).

The relevant software we're using is as follows:

• Operating system: Linux
  • Distro specifics aren't necessarily important. Ideally, whichever distro is chosen will have a robust package ecosystem. If not, you may need to become familiar with building software from source.
• Web server: Nginx
  • Our sysadmin is most comfortable with Nginx, but Apache is more common, and will likely have more information on how to use it with MediaWiki.
• Database: MariaDB
  • Interchangeable with MySQL, but MariaDB was what was available from our distro's package manager.
• PHP (We're using PHP 7.4).
• MediaWiki 1.35
  • We acquired MediaWiki by downloading a zipped release from mediawiki.org, rather than checking out the REL1_35 branch from the MediaWiki repository on Gerrit.

We're also using the following optional software:

• Web cache: Varnish
  • We're proxying requests through Nginx in order to provide TLS termination and proxy requests to the application server.
• ElasticSearch
  • Used for CirrusSearch. Highly recommended - without it, there were many complaints about MediaWiki search, and negative comparisons to Fandom's search.
• Redis
  • Used for the job queue, main cache, and session cache. Highly recommended if using CirrusSearch.
  • NB: If using Redis with CirrusSearch, you must set up this service in order to remove jobs from "delayed" status.

To acquire data from Fandom, we used the grabber scripts available on mediawiki.org. This approach has several benefits over requesting a XML dump from Fandom:

• There's no need to request a database dump from Fandom.
• Content can be updated as edits are made to the Fandom wiki, rather than the XML dump being a snapshot in time.
• User, actor, and log data is imported, in addition to page and revision data.

However, the grabber scripts currently (2021-04-07) do not work with MediaWiki 1.35. We set up a MediaWiki 1.32 instance and ran the grabber scripts to populate that instance. We then cloned the database and ran the upgrade script to upgrade to MediaWiki 1.35. Inexplicably, though, we would sometimes get inscrutable RevisionAccessException errors when accessing pages after upgrading. We never determined a cause, and thus don't have any workarounds.

TODO: Discuss extension replacements for Fandom features; config and implementation details