[01:08:24] found a zuul bug/limitation while trying to push out the php5.5 change >.> https://gerrit.wikimedia.org/r/268031 [15:41:32] MatmaRex: What do I need to do to get https://gerrit.wikimedia.org/r/#/c/209570/ merged any time soon? [15:43:08] anomie: i suppose i could go and merge it [15:43:15] \o/ [15:43:18] it needs a rebase, though. probably just release notes. [15:44:50] MatmaRex: Yeah, just release notes. Done. [15:44:57] anomie: by the way, prateek was working on some keyboard accessibility improvements to CapsuleMultiSelect that you might be interested in, i added you to the patches. [15:45:17] I saw that in my email, which reminded me of ApiSandbox ;) [15:49:31] anomie: the patch is marked against https://phabricator.wikimedia.org/T98457 , which is marked as resolved - what's the actual status of that? [15:50:27] MatmaRex: Someone also fixed it in Extension:ApiSandbox at some point, I suppose. [16:04:12] anomie: hmm, recall when we talked about a bug in your rewrite, where some items in the dropdowns couldn't be selected, as if something invisible was covering them? i saw it again and debugged it this time [16:04:38] MatmaRex: The z-index issue with the overlay to make the disabled items clickable? [16:05:14] anomie: .mw-apisandbox-optionalWidget needs 'z-index: 0' in addition to 'position: relative', to create a new stacking context, otherwise .mw-apisandbox-optionalWidget-overlay with z-index: 2 will display on top of the dropdowns with z-index: 1 [16:05:16] yes [16:06:55] Ooh, that's a good fix. Done. [16:09:01] Except... then it makes popups for optional capsule selects and such go *under* subsequent fields. [16:10:30] oh? huh. hm. [16:11:47] anomie: hmm, i guess we should only apply z-index: 0 (and position: relative) to .mw-apisandbox-optionalWidget.oo-ui-widget-disabled? [16:13:00] * anomie tries that [16:13:30] .mw-apisandbox-optionalWidget { width: 100%; } [16:13:30] .mw-apisandbox-optionalWidget.oo-ui-widget-disabled { position: relative; z-index: 0; } [16:13:33] seems to work for me [16:14:09] alternatively, you could fiddle with $overlays, but that might be a pain in the butt and maybe we can avoid it [16:14:10] Me too. [16:17:38] yay [16:18:06] i'll look at it for a bit longer and merge it. [16:31:06] anomie: cahn you remind me what hook we use to change config after wfLoadExtensions() fires? [16:32:19] bd808: Nope. legoktm can tell us if he's around [16:32:33] * bd808 hunts for it some more [16:33:38] bd808: It looks like ExtensionRegistry::getInstance()->loadFromQueue() gets called from the top of Setup.php, so SetupAfterCache should work? [16:33:50] yeah! [16:33:52] thanks [16:34:29] Or $wgExtensionFunctions [16:36:24] oh that one is probably better [16:39:21] I might wind up adding a SetupFullyInitialized hook for stuff in T124367 (User::loadFromSession called before the end of Setup.php), too. [16:43:05] so many hooks :) [16:43:27] Grepping for wgExtensionFunctions in wmf-config made it look like the right choice [16:43:35] https://gerrit.wikimedia.org/r/#/c/268147/1 [16:44:27] * anomie wonders why wgExtensionFunctions isn't a hook, but figures it's probably hysterical raisins [16:48:30] yeah I don't actually see why it's not just a hook too [16:49:15] the code in Setup.php for wgExtensionFunctions is just a kind of cut down Hooks::run() [16:50:21] I guess one difference is that return values are ignored [17:01:51] bd808: i see https://www.mediawiki.org/wiki/Manual:Extension_registration#Attributes which might work if we defined something in extension.json for wikibase also [17:01:57] (which we don't have yet) [17:02:09] but this we want to set in config (e.g. local settings) [17:02:16] anomie: it's merged, yay :D do you want to close all the tasks or shall i? [17:02:25] i'm wondering if there is any recommended way? [17:02:36] MatmaRex: You can if you want, but I'll do it later if you don't. [17:02:38] anomie: actually. do you want to rename the Phab project for ApiSandbox? or create a new one? [17:02:47] * aude surely could come up with something hacky [17:03:01] aude: sounds like a great question for legoktm to answer and document on wiki [17:03:13] yeah... too bad he' sprobably not around [17:03:39] he'll be here in 6-8 hours or so probably [17:03:45] could probably stick something in the wikidata build [17:04:07] MatmaRex: I was planning on filing a task about archiving the MediaWiki-extensions-ApiSandbox project. The remaining tasks in there probably don't apply to the core version. Not sure if it really needs a new project versus just filing bugs under #MediaWiki-API though. [17:05:10] anomie: if you don't create a project for it, any bug reports are guaranteed to go all over the place. [17:05:27] they'll be in #-api, #-interface, #-specialpages, #-extension-apisandbox, and who knows where else. [17:06:21] MatmaRex: Well, the last would be archived, so hopefully not there. #-special-pages I'd expect too, but not #-interface. [17:06:26] anyway. i'll leave it to you then :) [17:07:14] anomie: i watch #-interface. the weirdest stuff ends up there. :P [17:07:33] MatmaRex: Well then, I can count on you to reassign it to the right project ;) [17:07:42] haha [17:12:05] 10MediaWiki-Core-Team, 10MediaWiki-extensions-ApiSandbox, 5MW-1.27-release-notes, 5Patch-For-Review, 5WMF-deploy-2016-02-09_(1.27.0-wmf.13): Use parameter types in ApiSandbox - https://phabricator.wikimedia.org/T34740#1994496 (10Anomie) 5Open>3Resolved a:3Anomie Resolved with {T89386}. [17:41:20] bd808: think i figured out a way [17:41:24] making a patch [17:41:34] (not to scary solution) [17:41:35] too [17:41:52] cool beans [20:58:55] https://github.com/GeSHi/geshi-1.0/commits/master is alive [21:01:48] Reedy: we're not going back, though -- there were other reasons for switching to Pygments. The biggest one is that each lexer in GeSHi uses a different set of HTML tags and class names to represent different kinds of tokens for the target language. As a result, each lexer has its own CSS stylesheet. We faced the choice of lumping all into a single, giant CSS module, even though only a tiny fraction would be used at one time, or [21:01:48] declaring >100 ResourceLoader modules -- one for each lexer. [21:02:30] pygments uses a common set of class names, and for that reason a single concise stylesheet works for all languages [21:03:27] I wasn't particularly suggesting we did :) [21:04:47] I guess it's good news for anyone still using GeSHi [21:05:23] The months of no activity isn't exactly good [21:11:06] bd808: I think I have patches for all the log messages in P2544 except for the ones via WikimediaEvents now. Turns out a lot of them filter through the same code paths. [21:11:46] anomie: nice [21:15:16] bd808: The WikimediaEvents one could use feedback from ori, nuria, or someone else who knows if there's a reason https://gerrit.wikimedia.org/r/#/c/247512/ uses RequestContext::getMain()->getUser() instead of $revision->getUser(). [21:19:05] Reedy, 'alive' is a strong word, look at what they actually changed... [21:19:23] It's more than the recent changes [21:19:36] oh, they merged a bunch of pull requests [21:19:48] I was looking at the dates shown on each commit :) [21:19:56] heh [21:21:21] anomie: it is probably fine to get the user via the revision object -- but why is getting it from the context causing T124367? [21:23:53] ori: NewUserMessage's AuthPluginAutoCreate hook function makes an edit before Setup.php finishes, and one of the things SessionManager does is logs that warning if something tries to load the user from session before the end of Setup.php because it screws up when there's auto-creation. [21:25:01] isn't it a bug in NewUserMessage, then? [21:26:30] Could go either way, really. [21:27:27] I'd be happy to merge a patch changing it to use $revision->getUser() instead. But this seems like a code smell to me -- things should be either OK to do or not OK to do. Being kinda-sorta-not-OK-but-you-might-get-away-with-it is bad. [21:46:11] Reedy: https://phabricator.wikimedia.org/P2558 [21:49:30] https://gerrit.wikimedia.org/r/#/c/267816/ [21:55:40] hhvm vs. php5 issue :/ [21:59:23] this still doesn't explain the importImages.php --overwrite problem [22:11:17] a combination of https://www.mediawiki.org/wiki/Special:Code/MediaWiki/55810 and https://github.com/wikimedia/mediawiki/commit/42e97bbebe8f1db9e30ad7a0c3cee6a14a087b82 looks suspicious but I'm pretty sure that option has worked since then... [22:15:31] $options gets set but not the 'overwrite' key [22:30:52] fuuu.... [22:31:02] UploadWizard is silly [22:31:39] aude/ bd808: could you file a bug about whatever docs are missing? [22:33:27] legoktm: sure. They may even exist and I just don't know where to look. The basic question was how to mix our multiversion config hacks with extension.json settings that aren't materialized until later. [22:35:38] what in the world is $wgMFSearchApiModules ?? [22:36:00] o.O [22:36:11] Those should probably be attributes. [22:36:26] legoktm: it's so that on wikidata, the api also requests pageterms [22:36:41] ah [22:37:01] i see how visual editor allows other extensions to register modules [22:37:09] https://www.mediawiki.org/wiki/Manual:Extension_registration#Attributes [22:37:17] that might be what we want here [22:37:50] but not sure we want to set it in wikibase itself or just the config [22:37:56] set/add [22:58:58] TimStarling: Sara Golemon finally got back to me regarding the output buffer patch I re-submitted on your behalf. She identified the internal test that is failing and gave some details regarding the failure. It is very little to go on, but if you are willing, please take a look and see if you can suss out what the problem is: https://reviews.facebook.net/D51855#986931 [23:00:36] better than nothing [23:33:46] TimStarling: I've lost track of the edit section links parser cache corruption bug, was the fix patch and the logging stuff backported to wmf.10?