Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Helping wikis move away from Fandom

weirdgloop.org

Post reply on HN
Print view View original

311–320 of 503 posts

Re: Helping wikis move away from Fandom

#311

Post by jampekka »

jabroni_salad wrote: post #214
thih9 wrote: post #170

Earlier quoted context omitted.

That is already the case: > The GDPR is specific that consent must be as 'easy to withdraw as to give', meaning that a reject-all button must be as easy to access in terms of clicks and visibility as an 'accept all' button. Source: https://en.wikipedia.org/wiki/HTTP_cookie#EU_cookie_directiv...

what is required is not the same as what happens in practice. Visit any wiki.gg site and see what they're doing.

The law is not enforced. The non-enforcement is largely by design/lobby though.

Re: Helping wikis move away from Fandom

#312

Post by Washuu »

forgotpwd16 wrote: post #177

Should mention the pessimistic possibility that Fandom buys WG and those wikis return under their umbrella. An example being Wowpedia forked off WoWWiki in 2010, moved to Curse's Gamepedia in 2013, which, Gamepedia, Fandom (then Wikia) bought in 2018. edit: Seems they moved again recently to wiki.gg.

The reason behind Fandom buying Gamepedia/Curse is both a blessing and a curse(HAH!) that would require a specific set of circumstances to happen again.[1]

Basically during 2018 Curse's owners, Twitch and Amazon, wanted more head count for Twitch and to cut out anything that was not part of Twitch's main mission. The decision at the time from the Twitch CEO was to completely shut down Curse and fire everyone by the end of 2018 even though Curse was a cash positive subsidiary. That would mean turning off every single wiki with no transfer to anywhere else. It would all just be gone.

So the director of Curse at the time worked his ass off find a buyer for the company. The final options came down to The Verge, Wikia, and one other that I forgot. Essentially Wikia was the only one that could promise to meet all of the buyout terms and a two year transition period of employee benefits for current employees.

I'm not going to call Wikia a savior here, but without any company offering to buy Curse a lot of wikis and jobs may have been lost that December.

[1]I signed some NDA about this, but it has been many years and I don't care.

Re: Helping wikis move away from Fandom

#313

Post by bawolff »

noen wrote: post #209
jchw wrote: post #103

Earlier quoted context omitted.

In all fairness, running modest to large MediaWiki instances isn't easy. There's a lot of things that are not immediately obvious: - For anything complex/large enough you have to set `$wgMiserMode` otherwise operations will just get way too long and start timing out. - You have to set `$wgJobRunRate` to 0 or a bunch of requests will just start stalling when they get assigned to calculate an expensive task that takes…

This is so true. I adopted mediawiki to run a knowledge base for my organization at Microsoft ( https://microsoft.github.io/code-with-engineering-playbook/I... ). As I was exploring self-host options that would scale to our org size, it turned out there was already an internal team running a company wide multi-tenant mediawiki PLATFORM. So I hit them up and a week later we had a custom instance and were off to the ra…

Microsoft did open source a bunch of their mediawiki extensions. https://github.com/microsoft/mediawiki-extensions

Last i heard though they were moving off it.

Re: Helping wikis move away from Fandom

#314

Post by dingnuts »

hiatus wrote: post #267
Imustaskforhelp wrote: post #189

Earlier quoted context omitted.

How is it making money?

It is described in the linked article. > The company primarily relies on three streams of revenue: user donations, serving ads on select Weird Gloop wikis, and a contract with Jagex that includes a fee to cover hosting and administration costs.

I didn't see anything in the article about setting up incentives to keep the same thing from happening to Weird Gloop that happened to Fandom, which means the blog post is just empty marketing.

The only difference is that Weird Gloop is the little guy. Competition is good! That might be a good enough reason to choose them if you're in the market for wiki hosting!

But the moral posturing won't last if they become dominant, unless they set up incentives fundamentally differently than Fandom did, which doesn't seem to be the case.

As long as advertising is one of their revenue sources, the user experience will get crappy as soon as the network effects make it hard to leave. The cycle continues.

Re: Helping wikis move away from Fandom

#315

Post by j3s »

robjwells wrote: post #4

> [This post] (and many others) have done a much better job than I could, explaining from a reader’s perspective why Fandom is bad place to host a wiki, The linked post (at j3s.sh) appears blank to me, so if others have the same problem here’s an archive link: https://archive.ph/kwt1b

oop, my bad. it got oomkilled somehow - should be back up now :3

original post is at https://j3s.sh/thought/stop-using-fandom.html

Re: Helping wikis move away from Fandom

#316

Post by bawolff »

jchw wrote: post #234
account42 wrote: post #178

Earlier quoted context omitted.

A lot of things should be solved by having (micro)caching in front of your wiki. Almost all non-logged in requests shouldn't even be hitting PHP at all.

In my experience this hasn't been necessary yet on anything I've ran. I know WMF wikis run Varnish or something, but personally I'm trying to keep costs and complexity minimal. To that end, more caching isn't always desirable, because RAM is especially premium on low-end boxen. When tuned well, read-only requests on MediaWiki are not a huge problem. The real issue is actually just keeping the FPM worker pool from get…

Varnish caching really only helps if the majority of your traffic is logged out requests. Its the sort of thing that is really useful at a high scale but matters much less at a low scale.

Application level caching (memcached/redis/apcu) is super important even at a small scale.

Most of the time (unless complex extensions are involved or your wiki pages are very simple) mediawiki should be io-bound on converting wikitext -> html (which is why caching that process is important). Normally if db is healthy, db requests shouldn't be the bottle neck (unless you have extensions like smw or cargo installed)

Re: Helping wikis move away from Fandom

#317

Post by dpbriggs »

ykonstant wrote: post #49
paranoidxprod wrote: post #45

A few years ago, Path of Exile migrated from the fandom to a new site. GGG (Path of Exile's company) even decided to host the new wiki on their servers ( https://www.pathofexile.com/forum/view-thread/3292958 )! At this point, the new wiki ranks higher then the old one, but for a time it was an issue. Interesting to see more cases of games wikis leaving Fandom with how horrible the site is, and hopefully this is just…

Fandom PoE still pollutes the top of Google searches :(

There is an extension which automatically redirects you from Fandom to the new wiki. While that's convenient it probably helps Fandom stay near the top.

Re: Helping wikis move away from Fandom

#318

Post by bawolff »

starkparker wrote: post #264
giantrobot wrote: post #252

Earlier quoted context omitted.

Making MediaWiki survive non-trivial amounts of traffic is much harder than simply setting it up. It's not an impossible task for sure but there's no one click performance setting.

Specifically, managing edge and object caches (and caching for anonymous viewers vs. logged-in editors with separate frontend and backend caches) while mitigating the effects of cache misses, minimizing the impacts of the job queue when many pages are changed at once, optimizing image storage, thumbnailing, and caching, figuring out when to use a wikitext template vs. a Scribunto/Lua module vs. a MediaWiki extension…

Everything is hard at scale. You have to be pretty big scale before some of that stuff starts to matter (some of course matters at smaller scales)

Re: Helping wikis move away from Fandom

#319

Post by Kiro »

layman51 wrote: post #282
Kiro wrote: post #224

Earlier quoted context omitted.

And yet, when YouTube cracks down on adblockers, people on here get outraged instead of just paying for Premium. Everyone keeps saying "just let me pay" but when the option exists, it seems like most still avoid it and stick to complaining.

I read that in their battle with adblockers, the YouTube team seems to have broken Premium at least once. I think they were accidentally showing banner ads to Premium users.[1] It seems kind of odd, but wouldn’t your money be better off being spent on helping the ad-blocking effort rather than paying websites that seem to offer a gradually worse experience for everyone who isn’t blocking ads? [1]: https://old.reddit.…

Yes, that's certainly an odd argument. Why would I do that when I'm happy with the service I'm paying for? Especially when it's the best way to support the creators I enjoy, since they get a much bigger share of revenue from Premium views than regular views.

Re: Helping wikis move away from Fandom

#320

Post by 35skill »

dingnuts wrote: post #314
hiatus wrote: post #267

Earlier quoted context omitted.

It is described in the linked article. > The company primarily relies on three streams of revenue: user donations, serving ads on select Weird Gloop wikis, and a contract with Jagex that includes a fee to cover hosting and administration costs.

I didn't see anything in the article about setting up incentives to keep the same thing from happening to Weird Gloop that happened to Fandom, which means the blog post is just empty marketing. The only difference is that Weird Gloop is the little guy. Competition is good! That might be a good enough reason to choose them if you're in the market for wiki hosting! But the moral posturing won't last if they become domi…

Did you read the post? There's a whole section talking about how they are entering into binding agreements that let communities leave (and take the domain) if they have a better option
Post reply on HN