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...?
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 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
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.
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...
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.
I would recommend Cargo instead of SMW, Cargo lets you use an RDB more directly, and you can do much more powerful things as a result. Cargo has been a better option than SMW since about 2018 or so imo
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...?