[00:03:59] <bd808>	 ok that happens because intFunction calls ParserOptions::getUserLangObj which does "$this->optionUsed( 'userlang' );"
[00:04:32] <bd808>	 so we are really just back and garbage making it into ParserOptions::mUserLang
[00:05:19] <brion>	 yups :(
[00:07:43] <brion>	 well i'll be a simian's avuncular relative
[00:07:51] <brion>	 sanitizeLangCode ain't doing shit
[00:11:28] <bd808>	 doh... if !$code
[00:11:35] <bd808>	 so anything non-falsy works
[00:12:27] <brion>	 ok so apparently Language::isValidCode() lets all kinds of bullshit through
[00:12:27] <brion>	 but does strip out path traversals and non-title chars
[00:12:27] <brion>	 for compatibility with weird hacks of some unspecified sort
[00:12:27] <brion>	 i think we "just" need to make sure the value is urlencoded
[00:12:27] <brion>	 so now my question is why is it not in production o_O
[00:13:46] <brion>	 yeah i think it was originally meant to let through things we just hadn't localized yet
[00:14:53] <brion>	 yeah if you stick a <> in there instead of the unicode curly versions it falls back to english, and doesn't store the !userlang= on the pcache key
[00:15:58] <bd808>	 so it's only unicode that breaks it?
[00:16:08] <bd808>	 =poooop is fine
[00:16:52] <RainbowSprinkles>	 poooop will be perfect for ISO-639-6 :p
[00:17:53] <brion>	 :)
[00:18:15] <bd808>	 oh. unicode breaks it at the memcache layer. right
[00:18:38] <brion>	 i wonder what %00 does
[00:19:13] <brion>	 yeah it doesn't like %00 either :D
[00:19:55] <bd808>	 and validation is shit so things like https://commons.wikimedia.org/w/index.php?title=Special:Upload&uselang=ownwork work
[00:20:29] * brion cries one lonely tear
[00:20:41] <bd808>	 T39587
[00:20:41] <stashbot>	 T39587: character filter for uselang - https://phabricator.wikimedia.org/T39587
[00:24:47] <bd808>	 so... add unicode byte markers to the strcspn() call?
[00:24:56] <bd808>	 rethink the whole thing?
[00:26:29] <brion>	 bd808: my inclination would be to just url-encode the string values going into the pcache
[00:26:42] <brion>	 the thing that really confuses me is *that's what happens* right now in my mw-vagrant install o_O
[00:26:46] <brion>	 and i have no idea how
[00:29:24] <brion>	 hmmmm
[00:29:41] <brion>	 MemcachedBagOStuff::makeKeyInternal does use rawurlencode
[00:29:52] <brion>	 in makeKeyInternal
[00:30:07] <bd808>	 unicode is url safe
[00:31:00] <brion>	 but in production it's a MultiWriteBagOStuff that is used initially
[00:32:12] <brion>	 and it doesn't override BagOStuff's base implementation of makeKeyInternal
[00:32:25] <brion>	 which does *not* urlencode anything
[00:32:51] <brion>	 yeah i think that's it
[00:32:53] <bd808>	 maybe that should be changed with a big release note
[00:33:28] <bd808>	 making cache keys sane makes sense generally
[00:35:12] <brion>	 yeah
[00:37:58] <brion>	 at least we got to the bottom of it \o/
[00:38:52] <brion>	 is the Multiwrite one new? i feel like that's been there a while (redis etc) but i haven't poked too much in that area
[00:44:51] <bd808>	 it's probably about a year old now. Aaron made it for multi-dc stuffs
[00:47:57] <brion>	 Yeah, that explains the intermediary usage. Replication et al
[18:23:26] <milimetric>	 tgr|away: hey, I need some help on https://phabricator.wikimedia.org/T166335 if you have a sec
[18:23:53] <milimetric>	 or anyone else that might know why this JsonConfig-based extension works fine via index.php but throws errors via api.php
[18:24:24] <milimetric>	 I looked at it and I kind of get what's happening but I don't know enough about how extensions should interact with the api
[18:28:46] <MaxSem>	 yeah, but that array still doesn't contain 'class', right? :P
[18:31:13] <MaxSem>	 milimetric, so why don't you just define it?
[18:32:34] <milimetric>	 I don't know what that means... I thought it couldn't find the class I defined there, DashikiView
[18:33:27] <milimetric>	 like that this extension.json code points to it so that index.php can get to it, but not api.php somehow
[18:33:33] <milimetric>	 https://github.com/wikimedia/mediawiki-extensions-Dashiki/blob/wmf/1.30.0-wmf.2/extension.json
[18:33:56] <milimetric>	 so I'm reading the error message wrong... hm
[18:34:09] <MaxSem>	 don't concentrate on scenarios when this happens, the error clearly states what to do
[18:35:15] <tgr>	 milimetric: did you change the config recently?
[18:35:18] <milimetric>	 maybe if you're familiar with php and/or mediawiki, but to me it's pretty greek
[18:35:36] <milimetric>	 yes, but before it was completely broken
[18:36:00] <tgr>	 does it come from the private repo on tin?
[18:36:03] <milimetric>	 so this is "correct" as far as testing via the normal interface: like https://en.wikipedia.beta.wmflabs.org/wiki/Config:Dashiki:Test
[18:36:42] <milimetric>	 mediawiki config just loads Dashiki, and the config is just this blurb in extension.json
[18:36:52] <milimetric>	 I don't know exactly how the deploy works, but I'm pretty sure there are no private repos
[18:38:27] <milimetric>	 so this is the source: https://github.com/wikimedia/mediawiki-extensions-JsonConfig/blob/wmf/1.30.0-wmf.2/includes/JCSingleton.php#L403
[18:38:32] <milimetric>	 (of the error)
[18:38:55] <milimetric>	 so I get that config in extension.json should have something like class: 'blah' but I don't know what 'class' should e
[18:38:56] <milimetric>	 *be
[18:39:41] <MaxSem>	 since you didn't define your own content class, use something from JsonConfig
[18:40:02] <MaxSem>	 maybe JsonConfig\JCObjContent?
[18:41:18] * RainbowSprinkles sighs at JsonConfig
[18:42:02] <milimetric>	 just like that?  "class": "JsonConfig\\JCObjContent"?
[18:44:02] <milimetric>	 I looked at the other JsonConfig extensions and they don't have such a thing... maybe they never get called by the api?
[18:49:04] <milimetric>	 ok, put up a patch, Max I'll add you let me know if you're swamped though
[19:43:43] <RainbowSprinkles>	 Whee, more JsonConfig fun!
[19:44:04] <RainbowSprinkles>	 Warning: No content is available, caching empty '486:Sample.tab' for 10 seconds [Called from JsonConfig\JCCache::memcSet in /srv/mediawiki/php-1.30.0-wmf.4/extensions/JsonConfig/includes/JCCache.php at line 99] in /srv/mediawiki/php-1.30.0-wmf.4/includes/
[19:44:24] <RainbowSprinkles>	 Warning: Unable to get config content: title=Data:Sample.tab, result={"ns":486,"title":"Data:Sample.tab","missing":""} [Called from JsonConfig\JCUtils::warn in /srv/mediawiki/php-1.30.0-wmf.4/extensions/JsonConfig/includes/JCUtils.php at line 53] in /srv/
[19:44:30] <RainbowSprinkles>	 (eh, cut off end of file, but same crap)
[19:57:44] <MaxSem>	 RainbowSprinkles, this sounds like these should be converted to logging
[19:58:43] <RainbowSprinkles>	 If you log an error and nobody cares to fix it, does it matter?
[19:58:46] * RainbowSprinkles sighs
[19:59:20] <RainbowSprinkles>	 Also: "/bin/bash: svn: command not found"
[19:59:22] <RainbowSprinkles>	 wut?
[19:59:46] <RainbowSprinkles>	 Special:Code
[19:59:48] <RainbowSprinkles>	 ?
[20:00:04] <MaxSem>	 told ya it needs to be undeployed
[20:00:47] <RainbowSprinkles>	 Find a way to archive the data.
[20:01:35] <MaxSem>	 /dev/null
[20:21:03] * MatmaRex slaps MaxSem around a bit with a large trout
[20:21:35] * MaxSem throws the trout into /dev/null too
[20:22:10] <MatmaRex>	 it's astonishing how much stuff people broke in the SVN era that i still run into when git blaming things. and occasionally, CodeReview comments contain something useful.
[20:22:53] <anomie>	 ^ What MatmaRex said. Although it's sadly very occasionally, too often no one left any comments.
[21:24:59] <RainbowSprinkles>	 We could probably get away with some kind of static HTML dump of it.
[21:25:03] <RainbowSprinkles>	 Long as the URLs redirect (easy)
[21:25:19] <RainbowSprinkles>	 Doesn't need to be fancy. Importing to Phab would be a useless exercise