[07:34:51] 234567 [15:51:09] New here, hello world. I'm deploying an experimental fork of Wikipedia and I'd like to allow WP registered users to edit my wiki as well, in addition to local users. I've looked into the CentralAuth extension and the Unified Login service (https://meta.wikimedia.org/wiki/Help:Unified_login) and that looks easy enough to deploy. However the relevant [15:51:10] help page mentions "The global account system is only available for open Wikimedia projects; sites which run on the MediaWiki software but are not operated by the Foundation will continue to have separate account systems, even if they installed CentralAuth extension," This looks like a blocker. Can somebody advise whether an external wiki can [15:51:10] accept logins from SUL users, and how? [15:51:50] Werkmeister: You can use OAuth to federate with SUL users [15:53:18] Werkmeister: https://www.mediawiki.org/wiki/Extension:MediaWikiAuth or https://www.mediawiki.org/wiki/Extension:WSOAuth [15:53:46] Werkmeister: Also if you want to do something complex and custom, https://www.mediawiki.org/wiki/Manual:SessionManager_and_AuthManager is the programming documentation [15:55:34] in general, CentralAuth is complicated enough so that you don't want to run it unless you're absolutely forced to [15:57:04] Werkmeister: the sentence you found from the help page just means that Wikimedia accounts can't be used on third party wikis (because they're hosted completely separately) [15:59:10] so if you want to make it possible to log in to your CentralAuth family using a Wikimedia account, you'd need a separate extension like the ones bawolff mentioned above. but I suspect CA will not work with them out of the box because it wasn't designed to do that [16:00:45] you'd have to do a custom $wgAuthManagerConfig at the very least [16:09:47] taavi: Extension:MediaWikiAuth looks like exactly what I need, thx! [16:11:41] My project involved a single wiki at the moment, so a local user db is enough. I'll implement my own CentralAuth if/when we need to deploy our own familiy of wikis. [16:20:36] Please don't use MediaWikiAuth, that's a horrible extension meant for interacting with horrible sites which do not provide sane login options. You'll probably be blocked or banned or something if you try to harvest people's Wikimedia passwords. [16:22:38] oops, there's no intent of harvesting any personal data, let alone passwords! We just want to allow existing WP editors to transition smoothly to our project. What do you suggest? [16:25:28] WSOAuth worked pretty well for us, although we did not have deal with pre-existing users. [16:25:32] https://wikispore.org/ [16:26:23] Does WP provide an OpenID service? [16:28:02] Kinda sorta. https://phabricator.wikimedia.org/T254063#8082765 [16:28:11] We'd also like to interact smoothly with Wikidata and Commons [16:29:35] * TheresNoTime is interested wrt "experimental fork".. link? :D [16:30:33] "interact with commons" a la https://www.mediawiki.org/wiki/InstantCommons ? [16:30:48] Yes, InstantCommons [16:31:08] WSOAuth also kinda worked for me in the Not Wikilambda, though I never managed to figure out why sessions expired so quickly [16:31:24] Re:link, it's not live yet, will be happy to share asap [16:31:35] and I think by default WSOAuth supports local accounts at the same time (and I had to change the config to disallow those, since I only wanted login via OAuth) [16:31:47] in the Not Wikilambda *wiki, oops [16:33:07] bawolff has an InstantCommons extension IIRC, to get around performance problems in the core feature. You can use UnlinkedWikibase by samwilson for Wikidata integration. [16:33:24] Oh, i didn't realize that MediaWikiAuth was actually using password logins. Definitely reccomend avoiding that if possible [16:35:27] !e QuickInstantCommons [16:36:07] So it looks like Wikispore only allows SUL logins from meta, but the WSOAuth extension can be configured to also accept local users, is that right? [16:36:10] oh guess that doesn't work here. Anyways https://www.mediawiki.org/wiki/Extension:QuickInstantCommons is my version of instant commons, it has a little bit better performance than the core version of instant commons [16:36:51] bawolff: shilling your extensions I see, tsk tsk /j :p [16:36:52] bawolff: thanks I'll try that [16:37:07] TheresNoTime: tgr started the shilling ;) [16:37:41] :P [16:37:43] that's not shilling, that's sharing what we know in the wiki spirit O:3 [16:39:05] Yeah there are multiple options to make WSOAuth coexist with local login (you can make it assume that the preexisting local account with the same name is automatically the same user, or require users to connect accounts manually), I haven't tried them personally though. [16:41:55] mmmh nice performance bragging there X-P  "It took 1038.18 seconds with MediaWiki core's instant commons, 18.50 seconds with this extension with prefetching disabled, and 1.10 seconds with this extension but with prefetching enabled." [16:57:43] I've also been wondering about the search engine configuration and performance. Read up from https://wikitech.wikimedia.org/wiki/Search and that looks a bit overkill. What search config would you recommend when running a pretty large wiki (enwiki clone) with very little traffic? [16:59:03] Werkmeister: you should probably jump in #wikimedia-search. The search people hang in there most of the time. Note that most of our US folks are out today, so you might have better luck tomorrow. [16:59:43] Probably CirrusSearch if you are expecting people to actually search things. The builtin search is kind of terrible, and not just in a performance way [17:00:14] But you probably don't need the hardcore level of redundency that WMFs setup does [17:02:05] Werkmeister: depending on your rate of changes, something similar to jobqueue might be needed. [17:02:42] We also aggregate peripheral signals into search (page views, some data coming from ORES, ...). All that might or might not make sense in your context. [17:05:23] Yes I planned to use CirrusSearch but I reckon I can get by with just one ElasticSearch instance. Do you know how much of an index size I should expect based on the roughly 100 GB wikitext for the full enwiki (latest revisions only)? [17:08:35] We have ~1TB of primary indices for enwiki (without counting replication). Your mileage may vary, depending on what you index [17:13:11] I bet a large share of the index is consumed by 20 years of talk pages. Do you have a guess as to the index size for just the Article namespace?