4 ms·

Miraheze is the main replacement to Fandom -- it's an ad-free, community-owned, nonprofit supported entirely by donations, grants and volunteers. We've been op

Miraheze is the main replacement to Fandom -- it's an ad-free, community-owned, nonprofit supported entirely by donations, grants and volunteers. We've been operating free wikis on MediaWiki for about 9 years now, supported through different organizations, but right now we're the fastest and most stable we've ever been. Like all OSS efforts, we can always use more technical volunteers. I'm Chair and Acting President of the WikiTide Foundation, the parent of Miraheze, and I'd be happy to answer any questions about the service. Our users are generally more anti-Fandom than this article is, in my experience. For paid offerings, with a little more freedom than a wiki farm host can allow, WikiTeq, MyWikis, and WikiWorks are all good offerings in the MediaWiki space. I currently work for WikiTeq, but they're all pretty good, and the owners are on friendly terms with each other, with a lot of them coming in through the Wikimedia community or staff.

solardev 2y ago
Can I ask what your stack is? I used to volunteer at another nonprofit wiki (not a host, just a single wiki). I had a lot of trouble trying to manage the MediaWiki LAMP stack, especially when you have to add things like Varnish with proper integration or Parsoid (I think back in the day it was a separate, standalone server that needed root). MediaWiki Updates weren't easy either. Is it still that difficult these days, or is there some readily-available containerized version now? Cloudways for a while had a managed MediaWiki VM offering, but they discontinued that I think. Are there standard best practices for hosting MediaWiki these days, or is that part of your secret sauce...?
- labster 2y ago
  The stack at Miraheze is all open source, and almost entirely available free on GitHub. The overview is here: https://meta.miraheze.org/wiki/Tech:Home https://meta.miraheze.org/wiki/Tech:Home We do a few things that aren't recommended, like running WMF's own CentralAuth, which you definitely wouldn't want to do if you were hosting one or two wikis, as well as upgrading with every new MW release. Generally I would go with Canasta, a Docker image that's collectively maintained by a few MediaWiki companies. Canasta upgrades with every LTS release, which is a much easier pace for maintainers. https://github.com/CanastaWiki/Canasta https://github.com/CanastaWiki/Canasta
  - solardev 2y ago
    Thank you so much for this answer!
- starkparker 2y ago
  Not affiliated with Miraheze, but with an independent self-hosted wiki. Parsoid got ported to PHP and made a core feature in 2019 and no longer requires being run as a separate Node.js service. The Visual Editor (which most people ran Parsoid to get) just works out of the box now. Update difficulty scales about evenly with the number of third-party extensions you rely on, especially if CirrusSearch or Semantic MediaWiki are among them. But if you stick to stock and to the LTS version line, it's relatively painless since 1.19 compared to before it. Between general PHP performance improvements and php-fpm compatibility, it's frankly overkill to run anything beyond the official mediawiki:lts-fpm Docker image[1] while applying whatever PHP config changes you need for your use cases to the Dockerfile. Throw in SQLite improvements and even bare-metal admin isn't much of a hassle these days compared to the bad old days of juggling PHP versions and extensions, configuring Varnish, running Parsoid, patching Mediawiki extensions and skins, and doing MySQL/MariaDB/Postgres upgrades. A handful of well-supported responsive Mediawiki skins also means the stupid mobile-domain tricks aren't necessary anymore for most users to have a decent experience. 1: https://hub.docker.com/_/mediawiki/tags https://hub.docker.com/_/mediawiki/tags
  - solardev 2y ago
    Glad to hear! It was indeed VisualEditor we were trying to get working back then, along with Semantic MediaWiki :( It was the 2nd most difficult software I ever had to work with in my career (#1 being Drupal). Sounds like it's improved a lot since then. I'll have to check back in with that wiki I used to help with and see what they're doing these days...
    - starkparker 2y ago
      SMW is such a powerful tool, but it's designed like its target audience is mind readers who can divine what it needs to function. It either installs without issue or fails so cryptically that support is impossible. In pursuit of being a generic tool, the end-user docs and help are still so allergic to examples for its esoteric query syntax or use cases for property design that SMW effectively doesn't even exist for non-admins. Its extension-specific database changes are still their own hassle to upgrade separate from MW's. And the closest thing to an active support community is a Sourceforge email list. Cargo's still easier to work with and its query syntax is a lot more SQL-like, even with the reduced feature set.

solardev 2y ago

Can I ask what your stack is? I used to volunteer at another nonprofit wiki (not a host, just a single wiki). I had a lot of trouble trying to manage the MediaWiki LAMP stack, especially when you have to add things like Varnish with proper integration or Parsoid (I think back in the day it was a separate, standalone server that needed root). MediaWiki Updates weren't easy either. Is it still that difficult these days, or is there some readily-available containerized version now? Cloudways for a while had a managed MediaWiki VM offering, but they discontinued that I think. Are there standard best practices for hosting MediaWiki these days, or is that part of your secret sauce...?

labster 2y ago
The stack at Miraheze is all open source, and almost entirely available free on GitHub. The overview is here: https://meta.miraheze.org/wiki/Tech:Home https://meta.miraheze.org/wiki/Tech:Home We do a few things that aren't recommended, like running WMF's own CentralAuth, which you definitely wouldn't want to do if you were hosting one or two wikis, as well as upgrading with every new MW release. Generally I would go with Canasta, a Docker image that's collectively maintained by a few MediaWiki companies. Canasta upgrades with every LTS release, which is a much easier pace for maintainers. https://github.com/CanastaWiki/Canasta https://github.com/CanastaWiki/Canasta
- solardev 2y ago
  Thank you so much for this answer!
starkparker 2y ago
Not affiliated with Miraheze, but with an independent self-hosted wiki. Parsoid got ported to PHP and made a core feature in 2019 and no longer requires being run as a separate Node.js service. The Visual Editor (which most people ran Parsoid to get) just works out of the box now. Update difficulty scales about evenly with the number of third-party extensions you rely on, especially if CirrusSearch or Semantic MediaWiki are among them. But if you stick to stock and to the LTS version line, it's relatively painless since 1.19 compared to before it. Between general PHP performance improvements and php-fpm compatibility, it's frankly overkill to run anything beyond the official mediawiki:lts-fpm Docker image[1] while applying whatever PHP config changes you need for your use cases to the Dockerfile. Throw in SQLite improvements and even bare-metal admin isn't much of a hassle these days compared to the bad old days of juggling PHP versions and extensions, configuring Varnish, running Parsoid, patching Mediawiki extensions and skins, and doing MySQL/MariaDB/Postgres upgrades. A handful of well-supported responsive Mediawiki skins also means the stupid mobile-domain tricks aren't necessary anymore for most users to have a decent experience. 1: https://hub.docker.com/_/mediawiki/tags https://hub.docker.com/_/mediawiki/tags
- solardev 2y ago
  Glad to hear! It was indeed VisualEditor we were trying to get working back then, along with Semantic MediaWiki :( It was the 2nd most difficult software I ever had to work with in my career (#1 being Drupal). Sounds like it's improved a lot since then. I'll have to check back in with that wiki I used to help with and see what they're doing these days...
  - starkparker 2y ago
    SMW is such a powerful tool, but it's designed like its target audience is mind readers who can divine what it needs to function. It either installs without issue or fails so cryptically that support is impossible. In pursuit of being a generic tool, the end-user docs and help are still so allergic to examples for its esoteric query syntax or use cases for property design that SMW effectively doesn't even exist for non-admins. Its extension-specific database changes are still their own hassle to upgrade separate from MW's. And the closest thing to an active support community is a Sourceforge email list. Cargo's still easier to work with and its query syntax is a lot more SQL-like, even with the reduced feature set.