[01:13:42] is there an extension for creating tabbed content using forms? [04:35:36] hello [05:07:48] Hi. [06:27:18] much talk. [09:22:41] hello [09:50:00] hello i need help for Building a page in Wiki [09:50:12] Can anyone build for me [10:06:24] hello [10:06:26] I need help [10:06:27] Hi vishal_, just ask! There is no need to ask if you can ask, if you already asked the question please wait for someone to respond [13:24:17] wm-bot: Good bot. [16:41:49] Hi. Can not install MediaWiki 1.29.2 on CentOS 7.4 [16:43:29] mw-config/index.php does not run. Help! [16:57:35] quit [16:57:43] [quit] [17:19:26] Personal success today. I just finished migrating 1,500+ wikis to using AWS S3 as a file backend. [17:19:51] Looking to get the file backend code approved later by legal for release. :D [17:20:17] \o/ [17:20:18] How many? :P [17:20:34] How many what? :O [17:20:45] That's a lot of wikis :) [17:21:15] 1,746 total wikis in the farm. [17:27:43] Trela: maybe you could rescue https://www.mediawiki.org/w/index.php?oldid=2539404 :) [17:30:21] Maybe. This is a one file drop in in includes/libs/filebackend/. Autoload.php has to be edited of course, but going that route since we are slowly forking MediaWiki due to all the base code edits we make. [17:31:43] is your fork public? and is there a reason why you're forking? :( [17:34:03] If I ever get another developer or two on my team I will have time to publicly maintain our version, but at the moment no. :( We have to edit several base AuthManager files to work for our farm authentication solution. Plus many other tiny fixes for other core files. [17:34:50] At the moment anything we maintain publicly is at: https://github.com/HydraWiki [17:35:03] You should be able to add it as an extension [17:36:01] Trela: any reason to not submit those tiny fixes upstream? [17:37:28] @legoktm: Seems like the Wikimedia team has the same issue my team does. Issues go into Gerrit and might get looked at six months later because there is just so much work coming in. [17:37:44] yep :( [17:38:59] Hard to justify to upper management, "I spent eight hours this week working with Wikimedia to contribute patches back.", when they want more revenue. [17:39:57] maybe you could set up something like https://src.wikihow.com/ ? and those of us who care could look at the diff and see which patches are suitable for upstream? [17:40:14] I would hope that more upstreaming of patches makes upgrading major versions easier [17:41:21] We actually have a diff storage on the master farm wiki where we keep track of it. Just not exactly public. :( [17:42:23] https://i.imgur.com/mvoZGpt.png [17:42:36] Which are pages storing diffs. :x [17:44:26] I did that for wikia once.. And saved it on my dev wiki [17:44:45] Trela: I bet you could get legoktm to review your includes/registration patches ;) [17:45:45] It may not be well received. :D [17:46:02] I don't mind working with people to figure out a way to implement the feature you actually want :) [17:46:32] I entirely changed how it merges configuration values. https://pastebin.com/MQy6yeBM [17:47:02] To get around issues with load order and such. [17:47:36] hmm [17:47:59] what's the load order problem? [17:48:12] I'm guessing you had multiple extensions setting the same config setting? [17:49:38] Also some cases where a setting would get set(Say, in LocalSettings.php) before it got processed by the registration processor and then not merging the setting. [17:49:57] Mainly arrays. [17:50:14] oh? it wasn't merging arrays? it should always merge arrays... [17:50:27] Trela: Did you write a unit test for it? :D [17:51:09] @Reedy: No, but I did validate it with a bunch of var_dumps at the time. >_> [17:51:17] lol [17:53:17] that's probably the ugliest part of extension.json [17:54:31] Trela: yeah, so I don't think I'd merge that patch, mostly because extensions shouldn't be sharing config settings (it throws exceptions in 1.30 now), they should use the attributes feature instead [17:54:40] though I'd be interested in a bug report about the arrays not merging properly [17:55:06] We will be merging MW 1.30 when it is released so my work around may go away. [17:58:50] < Trela> Hard to justify to upper management, "I spent eight hours this week working with Wikimedia to contribute patches back.", when they want more revenue. [17:58:59] I would question that [17:59:29] There is a lot of dirty laundry hidden behind that statement I can not talk about publicly. [17:59:31] I mean, it might be hard to justify to your upper management specficially :) but that would be their shortsightedness [18:00:01] maintaining that patch forever is almost certainly going to cost more than 8 hours [18:00:47] or, you go down the wikia way and get stuck on an old version of MediaWiki and unable to update for ten years [18:01:19] (is Hydra the videogame FAQ thing btw?) [18:01:24] And reinvent wheels, repeatedly [18:02:33] if you have feedback on what caused problems in AuthManager, that would be very welcome, even without patches [18:03:22] Trela: The morale of the story is... befriend people who'll do CR for you in mw core ;) [18:09:54] yeah sadly the only thing that works for core CR these days is to find someone to prod, but that does work at least [18:41:03] tgr|away: I'm not aware that this has ever been different. [18:42:56] tgr: oyeah there was an authmanager bug that I was going to report but I never figured out if it was a bug in authmanager itself or just my extension [18:43:28] had a user autocreated on login, and passed them off to the optional password change as a secondary action [18:43:50] if they changed passwords or hit skip, everything was great. If they browsed away, they were unable to log in with their current password [18:54:45] @Reedy: @tgr|away: Sorry, Cindy grabbed me into a meeting. :) [19:08:02] ok, i tried installing graphviz on 1.27 (distributed by debian), but it's complaining about the lack of `extension.json`, so i went and grabbed it from git and it doesn't like that flavor of extension.json. So is there a good one floating around? [19:11:00] require_once "$IP/extensions/GraphViz/GraphViz.php"; [19:12:53] you have to load it old-school? It'd be nice if the page said that [19:12:56] * astro73|work tries it [19:13:18] It's not been migrated [19:13:57] https://www.mediawiki.org/wiki/Extension:GraphViz isn't helpful about this, nor about the ImageMap dependency [19:14:02] * astro73|work goes to track that down [19:14:05] Reedy: thanks [19:14:16] I'm confused [19:14:21] It's all handwritten [19:14:23] Why is it so wrong? [19:16:08] it talks about "wfLoadExtension( 'GraphViz' );", which I don't think is a thing except for the development version [19:16:19] It's not even right on master [19:16:38] Oh, wait [19:16:41] It's onlt just right on master [19:16:49] yeah [19:16:53] 5 days ago [19:17:04] astro73|work: did you try downloading the 1.27 snapshot? https://www.mediawiki.org/wiki/Special:ExtensionDistributor?extdistname=GraphViz&extdistversion=REL1_27 [19:17:07] also, it installed and immediately said "The ImageMap extension is not installed.", which isn't documented either [19:17:18] legoktm: yup, that's the one i grabbed [19:17:35] ImageMap is distributed with the debian package, so that just needs wfLoadExtension('ImageMap'); [19:18:50] yeah, i saw that [19:18:54] ok, cool, that works [19:18:55] Sigh [19:18:56] thanks! [19:18:57] It's been migrated [19:19:08] But no one has moved ImageMap dependancy to extension.json [19:19:41] also, glad to hear there are real users of the debian package :D [19:20:09] Real users, [19:20:16] As to compared to what? [19:20:23] aliens [19:20:32] astro73|work: if you have any feedback on the process with using the debian package to install MediaWiki please let me know :) [19:20:33] Fake users [19:20:46] lizard people, installing debian packages to subvert humanity [19:20:47] legoktm: i can never remember where extensions are installed to [19:21:19] and there's certainly room for tooling in that regard [19:21:32] astro73|work: hmm, I documented that at https://www.mediawiki.org/wiki/User:Legoktm/Packages#Filesystem but I could also put that in the README.Debian [19:22:03] i mean, it helps, but then i'd have to remember to also look in .... /usr/share/docs/mediawiki? [19:22:20] yep, I'm not sure where else I could put it [19:22:29] man mediawiki? [19:22:29] :D [19:22:35] unfortunately, that's The Place [19:22:46] i'm just annoyed how spread out debian puts everything [19:23:07] legoktm: a huge unavoidable message in every part of mediawiki xD [19:23:35] yeah, there are advantages and lots of disadvantages to splitting it up [19:23:49] if you look in /var/lib/mediawiki though everything is symlinked into that [19:24:18] yeah, i just have to remember that [19:24:52] semi-related, is there an option to get the visual editor and graphviz etc to play nicer? It's kinda really ugly as is, and a quick google isn't turning up anything. [19:25:33] it's not broken or anything, just kinda ugly [19:29:24] legoktm: https://gerrit.wikimedia.org/r/#/c/396094/ [19:29:38] Then we can remove the stupid comment on https://www.mediawiki.org/wiki/Extension:GraphViz#From_the_MediaWiki_Extension_Distributor [19:30:33] astro73|work: you could ask in #mediawiki-visualeditor ? I suspect no one has done the work to integrate it properly [19:30:34] It's a problem in 1.27 and 1.28 it seems. 1.29 fixed [19:30:53] The instructions though [19:31:03] Why have a common part... [19:31:07] That has the same thing the other parts do? [19:33:36] Never mind the settings being completely broken [19:34:09] It's a mess [19:44:03] i'm out, thanks for the help! [19:54:33] Skizzerz: the login process in AuthManager is sort of kept in an undetermined state until all the secondary providers have a chance to finish, but that's not the case for account creation [19:55:09] once the primary provider is done, the user is created; everything after that can be thought of as a separate action [19:55:24] in this case, it's an automatic account creation via login [19:55:31] not explicitly visiting Special:CreateAccount [19:55:53] oh, sorry, wasn't reading carefully [19:57:01] as I said, I'm not sure if it's an issue with AM itself or with my extension :) [19:58:55] that part of the process is closer to account creation I think: it's considered to be finished after the primary provider is finished [19:59:27] secondaries can prevent the user from logging in but not the account from being created; that would be super hard to deal with [19:59:27] yeah, the user is definitely in the user table [20:00:09] just for some reason they seem to be unable to log in unless they complete the secondary thing (as opposed to browsing away). I haven't had time to dig into it yet [20:00:11] so it's the responsibility of the provider handling the autocreation to not leave the user in a state where it has no credentials to log in [20:01:19] so if for example nothing sets a password on autocreation and it would only happen in the secondary then before that step you have a user with no credentials [20:01:24] so chances are my extension needs to explicitly set the user's password in the primary provider? [20:02:01] if you rely on local passwords for authentication then that's something to think about, yes [20:02:06] ah, yeah that'd be it then [20:02:10] so extension issue :) [20:02:20] thanks tgr! [20:02:38] you could intentionally ignore it and let such users log in with a temporary password via the forgotten password feature [20:03:06] but if you can grab the password from some central service without user interaction, you should do that in the primary [20:03:14] yeah, that's an option too. On the wiki where it's being used email happened to be broken at the same time :P [20:03:26] I know what the password should be [20:03:29] I just need to set it [20:03:47] just assumed AM did it for me [20:04:10] more specifically in the autoCreatedAccount callback of the primary, I think [20:04:12] hmm [20:04:21] except autoCreatedAccount doesn't get passed $reqs [20:04:27] well, AM has no way of knowing what the password should be [20:04:35] point [20:05:17] autocreation can happen at any time, not just login, so you can't rely on any login-specific information for this [20:05:39] what other actions trigger autocreation? [20:05:49] although I guess there would need to be some weird interaction between multiple global auth extensions for that to actually happen [20:06:16] my autoCreatedAccount callback bails out if $source isn't my extension, so it'd only be cases where my provider did an autocreate [20:06:27] session providers which can authenticate the user despite it not having a local account/session [20:06:44] OAuth does that, for example [20:07:10] (extension in question is MediaWikiAuth, which performs what amounts to a user-authorized MITM against some external wiki) [20:07:23] it looks up the OAuth signature in a central DB, that results in a central ID, the user is autocreated with that [20:08:18] user logs in via password auth using external wiki's creds, the provider hits up the external wiki's API to auth and import necessary things locally, and autocreates the account. Once the account is created it only considers local auth for that account (or whatever other providers are enabled) [20:09:25] so yeah I don't think we have a neat way for that [20:09:25] useful for splitting from wikis which don't have OAuth installed (such as moving a wiki out of Wikia) [20:09:45] you'll just have to stash the password in some global-ish place and retrieve it in autoCreatedAccount [20:09:52] figures, thanks though [20:10:28] you can use AuthManager::setAuthenticationSessionData [20:10:48] ok, will look into that [20:11:12] but you don't really need to persist it between requests so just a member property should work too [20:11:54] right now persistence shouldn't be necessary. If I stop being lazy and start supporting whatever the remote action=clientlogin throws at me, then I would as I may need to redirect users, etc. [20:12:03] and then you might want to mark the password as expired so even if the user navigates away they still get the password change on next login [20:13:38] autoCreatedAccount is always going to be on the same request as the one where you returned a PASS from the primary, which can access $reqs, so there is no need for persistence [20:15:30] but consider a flow where user submits the password, I hit remote action=clientlogin, it sends a REDIRECT response, so I shift the user to some other page to handle that and then they bounce back. Will I still have access to the password when they return or will I need to store that? [20:15:57] answer: read the docs [20:16:56] continuePrimaryAuthentication is passed $reqs so all should be fine [20:35:41] hey! is it possible to create a template extracting data from all pages of a specific (infobox) template in the tabular form? [20:35:54] Let's say I'd like to create a special "all famous people in a table" page [20:38:10] !dpl [20:38:11] The DynamicPageList (DPL) extension outputs reports based on criteria given in a special tag. For more information, see and . [20:40:17] thanks saper ! [20:40:23] going to 34C3? [20:45:10] Semanticmediawiki is also used for that purpose [20:46:07] if you want to investigate competing solutions [21:22:06] alxd: nope