[02:45:55] TimStarling: Re: https://phabricator.wikimedia.org/T90849 I'm still not sure there are legitimate enough use-cases for opting out of having a global user page. I think __NOGLOBAL__ feels like feature cruft and I was supporting removing the functionality altogether. [02:47:17] I struggle to think that there are more than like a dozen users who really want a user page on Meta-Wiki, but don't want a user page on a local wiki. [02:47:22] But shrug. [13:22:10] legoktm: In that particular case, you'd need a function in engines/LuaCommon/TextLibrary.php to either build the nowikiReplMagic table currently in engines/LuaCommon/lualib/mw.text.lua, or return the flags so Lua could rebuild that table, or reconsider whether $wgEnableMagicLinks really needs to be in ParserOptions rather than just being a global that could be passed as part of the `opts` variable passed to mwtext.setupInterface. [13:22:31] tgr|away: Looks like lego beat me to it. [21:08:50] Dunno why I hadn't seen this in prod before, but seems easy enough to avoid the warning. https://gerrit.wikimedia.org/r/#/c/310438/ [21:09:00] (Warning: array_intersect_key() expects parameter 1 to be an array or collection in /srv/mediawiki/php-1.28.0-wmf.19/includes/MediaWiki.php on line 651) [21:33:36] bd808: Thanks [21:33:45] yw [21:34:29] bd808: My current warning/error/fatal goal is to get the group0 dashboard showing nothing. [21:34:39] So *anything* from those groups will show up [21:34:47] ostriches: god speed good sir [21:39:49] Um, what's this? [21:39:56] "file":"/srv/mediawiki/php-1.28.0-wmf.19/includes/SiteConfiguration.php","line":561,"message":"Failed to run getConfiguration.php.","code":0,"url":"/w/index.php?title=Special:CreateAccount&returnto=....... [21:40:01] There's a couple of those. [21:40:08] All on Special:CreateAccount group0. [21:40:47] does that come with a stack trace? [21:41:03] Indeed it does. [21:41:42] there is a comment right before that that says "ulimit5.sh breaks this call" [21:42:18] omg. that;s the horrible thing where the mainteance script gets called as a child proc [21:42:33] https://phabricator.wikimedia.org/P4038 [21:43:23] https://logstash.wikimedia.org/goto/872a3347f47a9e9e4e031fd476bd4030 [21:43:31] They come in pairs, all seem to be on special:createaccount [21:45:32] wow that looks scary [21:45:45] do we really do that on every cross-wiki job push? [21:45:48] blerg, /goto/ urls are broken on FF. [21:51:11] bd808: Minor nit on indexing stuff in logstash. Can we normalize {rdb_server} like we do {db_server} so A) messages get grouped and B) you can search by host then too? [21:51:55] ummm... sure. That has to be done in the MW code I think [21:52:13] Oh we should then :) [21:52:54] that magic in the UI comes from the log messages using the context and PSR3 placeholders [21:53:29] Hmm, we should. [21:53:40] $this->logger->error( [21:53:40] 'Could not connect to server "{redis_server}"', [21:53:40] [ 'redis_server' => $server ] [21:53:40] ); [21:54:15] yeah. that should show up as {redis_server} if you look at normalized_message [21:55:16] unless it happens on some path that MW's monolog logger isn't handling... [21:55:25] That's my thought tbh [21:55:29] I'm wondering if Redis->connect is already logging it somewhere [21:56:19] this filter keeps the un-expanded version for logstash -- https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/logging.php#L64-L91 [21:59:40] Looks like Zerowiki and/or JsonConfig is calling deprecated action=login methods from api.php [21:59:56] * bd808 is not surprised [22:00:19] zero+jsonconfig are only getting UBN fixes I think [22:00:34] * ostriches files a bug and sets to UBN [22:32:06] ostriches: they are using bot login, so it's not deprecated [22:32:41] Er, it's the tokens deprecation warning tho [22:33:49] that should not have any consequence [22:34:03] at least until it gets hard-deprecated [22:59:29] TimStarling, legoktm, AaronSchulz: It feels like we're further ingraining magic links instead of extricating them. [23:14:23] Debra: If the goal is to move magic links into an extension, then yes, my patch was a step backwards. If the goal is to kill them entirely (my preference), then I think it was a step in the right direction. [23:17:44] You think making them configurable with a default of on gets us closer to killing? [23:18:23] Maybe I'm just missing the bigger picture. :-) [23:20:51] Yeah, because now we actually have a way of turning them off. Say in 1.28 we announce that in 1.29 it'll be turned default off, and that gives us time to make sure extensions are updated. 1.29 turn it off by default, but if people turn it on it triggers a tracking category. Then 2-3 releases from then, we remove the feature from core, and leave ParserOptions getters that return false. Done! [23:22:19] An extension would've also been a way of turning them off, though. [23:22:24] And it would've moved the code out sooner. [23:23:00] I think adding an option signals to users/site admins that we're going to keep around the feature and support it. [23:24:06] Should we add a @deprecated tag to the configuration documentation? [23:24:24] I think an extension would have been more infrastructure work in Parser [23:24:50] I didn't realize how embedded magic links were, specially wfEscapeWikitext [23:25:36] A @deprecated tag, yes. [23:25:40] Or at least a note. [23:25:43] Being like "please don't". [23:26:06] Of course it'll say like "don't rely on this" and you're about to patch VisualEditor, Parsoid, and something else to rely on it? [23:26:10] Idk. [23:26:29] Is there another office hours scheduled related to you soon? [23:26:35] I saw an e-mail from Rob about shadow namespaces, maybe. [23:27:02] https://lists.wikimedia.org/pipermail/wikitech-l/2016-September/086443.html [23:27:21] > Qgil invited: ; uninvited: . [23:27:34] I guess https://phabricator.wikimedia.org/E269 ended up being about something else. [23:28:36] Something else --> Scribunto. [23:29:43] We mostly talked about WMDS in that one. [23:32:14] Debra: Parsoid/VE/Scribunto will depend upon the ParserOptions part, and we'd need to update then regardless of the fact that magic links might not exist right? [23:36:38] er, I meant to say: *we'd have to update them regardless, because magic links might not exist in core or the extension isn't enabled