[10:02:10] Nikerabbit: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/95185#c21253 i need suggestions for two points mentioned there [10:02:48] the messages for 'ok' & 'badretype' are there in the MessagesEn.php so I just used them, is it ok? [10:03:19] and instead of using $mUser can I use $tempUser ? [10:35:58] akshayagarwal: hello [10:37:01] akshayagarwal: 1) it's safer to add your own messages, in case those message are changed or removed in the core. because of translation memory it is not a problem for translators 2) yes [10:40:28] Nikerabbit: thanks! also could you just give me a hint on escaping the values in action=validatesignup&format=json ....... [10:40:56] i tried but ran into som errors [10:40:58] akshayagarwal: was it javascript code? [10:41:10] yes ajax call [10:42:29] hmm, I'm not so familiar with js [10:42:40] there's mw.Uri.encode but that is pretty recent addition [10:43:48] but there doesn't seem to me anything similar to wfArrayToCgi in js side [10:43:57] RoanKattouw: do you know what's the best way? [10:44:12] $.param() [10:44:29] can you give an example how to use that? [10:44:38] $.param( { 'foo': 'bar', 'baz': 'quux' } ) === 'foo=bar&baz=quux' [10:45:28] Also, if you're feeding stuff into any of the jQuery AJAX functions (like $.get(), $.getJSON() and $.post() ), they have a parameter where you can pass in an object with query parameters directly [11:04:53] RoanKattouw: data: $.param( {'action' => 'validatesignup', 'format' => 'json', 'field' => fieldtype, 'inputVal' => inputVal} ) [11:05:05] It's : not => [11:05:36] If you're passing this as the data: element for $.ajax() or its friends, you don't need $.param(), you can pass { 'action': 'foo', etc. } directly [11:06:36] oops, i made a silly mistake there [11:06:48] let me correct n check again [11:07:43] RoanKattouw: works! you'r the man! [11:22:06] RoanKattouw: didn't you fix the links in enotif emails a while ago? [11:22:20] I did [11:22:39] how much ago? [11:26:01] I half-fixed them early last week [11:26:09] Fully fixed since late last week [11:26:16] But the latter is not deployed [11:34:54] RoanKattouw: so I wonder why it is still happening on translatewiki... is lqt doing it itself? [11:35:11] I don't know [11:35:24] Do you get prot rel URLs in the entire message or are only some of them prot rel? [11:35:39] I didn't do extensions yet, so LQT might still be broken [11:36:06] Also, part of the fix was to change the enotif-body message to use {{canonicalurl:{{#special:Watchlist}}}} instead of {{fullurl:{{#special:Watchlist}}}} [13:31:50] Nikerabbit: have fixed most of the issues in r95185, do have a look :) [15:08:10] Hi neilk_ , I see you fixed the licenses :-) [15:08:38] multichill: hopefully, yes [15:08:57] So, you guys are deploying today? [15:53:38] neilk_ ^^ [15:54:07] multichill: yup, we have a scheduled deploy in a couple of hours. [15:54:20] ok, great :-) [16:23:34] hexmode: hi [16:47:59] Commons needs more WikiLove. Community consensus: Check. .js stuff: Check. Now I just need to find my bugzilla password ;-) [16:56:35] multichill, link me and I'll just do it? [16:57:18] Reedy: http://commons.wikimedia.org/wiki/Commons:Village_pump#WikiLove [16:59:18] multichill, done [17:03:49] Reedy: Thanks, it works (as you can see on your talk page now) [18:26:07] sumanah: Hi, Happy Janmashtami [18:26:30] hello, akshayagarwal, and the same greetings to you [18:26:44] sumanah: do you also fast today? [18:26:52] akshayagarwal: no, I don't [18:55:57] nice: https://bugs.php.net/bug.php?id=55439 [19:06:45] jorm: that one's pretty funny. [19:06:58] and by funny, I mean terrifying. [19:07:36] yeah. i'm wondering how one actually breaks that. [19:07:52] Look at the diff that fixes it ;) [19:08:42] where can i see that? [19:10:53] jorm: http://svn.php.net/viewvc/?view=revision&revision=315218 [19:11:32] click on the "text changed" bits. [19:12:07] wow. [19:12:28] http://svn.php.net/viewvc?view=revision&revision=314438 [19:12:31] That broke it [19:12:56] nice. [19:12:59] probably wasn't even tested. [19:14:11] everybody can still log in, what's the problem? ;) [19:15:28] oh and I hope everyone noticed who did this one... rasmus [19:17:25] haha [19:34:02] jorm: MD5 encryption for passwords is bad anyway ;-) [19:48:33] hlelo [19:51:39] neilk_: Trunk deploy of UW, right? [19:52:11] RoanKattouw: yes, but I was having some issues with conflicts, even when I just straight merged from UW [19:52:19] also, we need to deploy TitleBlacklist [19:52:21] first [19:52:42] I can rebranch for UW [19:53:02] ok, but I was close to done with 1.17wmf1 [19:53:20] I notice that you've been adding resource-loadery comments to my CSS, but only for prod? [19:53:25] ? [19:53:30] That's not very nice of me if that's true [19:54:43] There shouldn't be any revs that are in 1.17wmf1 but not in trunk [19:55:19] hm, wait a minute, I was sure this was some kind of issue [19:55:31] nm, I blame SVN, now I can't find these. There were conflicts [19:55:41] anyway, let's rewing [19:55:42] rewind [19:56:02] I'm suggesting we literally deploy trunk UW [19:56:12] However, you said you also need TitleBlacklist? [19:56:14] we could, you just copy it over? [19:56:16] yes we do [19:56:25] I'm assuming you need its API module? Are those revs reviewed? [19:56:34] yes, I reviewed those [19:56:48] Well shit, they are [19:56:53] OK so trunk deploy of TB, then trunk deploy of UW [19:57:06] but I want to double check because Krinkle & I moved around a lot of libraries from UW to /resources lately too [19:57:17] there might be a dependency now [19:57:35] was almost done getting 1.17wmf1 to work enough to detect if that is an issue. :( [19:57:49] btw, r95044 still needs a review [19:57:52] OK, you have local 1.17wmf1 install, right? [19:57:56] yes [19:58:00] Oh right, oops, missed that one [19:58:05] I was thinking I could just commit [19:58:11] once it looks good here, then we go to test [19:58:17] So do things work if you put trunk UW and TB on top of that? [19:58:19] and and and [19:58:33] UW deploy needs a schema change this time -- adding some tables [19:58:54] it's tagged w/scaptrap & schema [19:59:39] RoanKattouw: how do you do your "trunk" deploys, just svn copy? [19:59:46] svn delete then svn copy then [19:59:53] wow, scorched earth :) [19:59:56] Yes [20:00:04] it's easier than merge 1001 revisions [20:00:05] and cleaner [20:00:09] When merges annoy me too much, that's what I do [20:00:25] I have to admit that feels like what we could/should do [20:00:46] It's perfectly OK [20:01:59] OK, so [20:02:20] let's do it that way [20:02:23] 1) Do we need any other changes, e.g. in core, apart from going scorched earth (I like that term, thank you!) on TB and UW? [20:02:33] 2) What's the path of the .sql file that has the new tables? [20:02:47] I think we might need resources/mediawiki.uri.js but I'm not positive [20:02:59] We can try it out on testwiki [20:03:51] the sql files are in this revision http://www.mediawiki.org/wiki/Special:Code/MediaWiki/92413 [20:04:13] or, if you like, in this directory http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/UploadWizard/sql/ [20:05:30] Ah cool [20:05:43] Wait those are just index creations [20:06:10] no, there's a table in there too [20:06:12] two tables [20:06:15] Oh, UploadWizard.sql has been added too [20:06:20] D'oh, UW didn't have any tables previously of course [20:08:15] RoanKattouw: oh, that's nasty, the table definition files are in the root dir. never mind. [20:08:24] That's OK [20:08:40] anyway Jeroen used the new schema updater so all you have to do is install the extension and do php update.php [20:08:53] hehehehe [20:08:58] No, we don't use update.php on the cluster [20:09:22] It's weird how the indices are in separate files, but whatever [20:09:46] that's how the extension updater thing works, there are different operations for addTable and addIndex. [20:10:09] You can put your indexes in with the table creation [20:10:11] You're supposed to even [20:10:17] *RoanKattouw realizes there's a lot of undocumented conventions there [20:10:31] ok, that's how we thought we were supposed to use it [20:10:38] It's Ok [20:11:00] Alrigh [20:11:03] So let's go ahead with that [20:11:04] so am I doing this or are you [20:11:10] Table creations and scorched earth [20:11:17] You do the scorched earth in 1.17wmf1 and I'll do the tables [20:11:22] k [20:11:40] delete and copy, all in one change? it gives me heart palpitations. [20:12:54] No, in two separate revs [20:13:14] okay. oh, ffs, I think we will have to fix UploadWizardHooks. [20:13:25] Is it broken in trunk somehow? [20:13:34] no, it's right for trunk... wrong for 1.17. it points to mediawiki.libs.jpegmeta [20:13:48] I'll deal [20:14:08] Oh, right [20:14:17] You'll need to patch that after rebranching it I guess [20:14:42] Oh, meh [20:14:49] I can't do the tables without your commits :( [20:15:03] New division of labor: you do UploadWizard, I do TitleBlacklist [20:15:12] um, okay [20:15:36] (You were working on UW already, right?) [20:15:52] yes, but I'm doing it the "easy" way now. Also I need to copy over mw.Uri [20:15:57] OK [20:18:51] OK I've rebranched TitleBlacklist, I'm gonna try to deploy it to testwiki now [20:18:59] ok [20:19:41] all right, so what if we have a super big change and we only want a few bits and pieces of it. [20:19:59] ? [20:20:06] krinkle did some wholesale refactors to trunk resources... I only need 3 lines. I can just make an equivalent change in 1.17wmf1 [20:20:08] You want to partially merge a revision? [20:20:10] Sure [20:20:14] okay [20:20:23] In that case you should just use vim instead of svn merge [20:20:25] but it's not a merge as much as I'm just copying the lines over [20:20:27] yes [20:20:38] And mention it's a partial merge of rNNNNN done by hand [20:20:50] right, was going to do that [20:20:56] Also: https://bugzilla.wikimedia.org/show_bug.cgi?id=30505 (probably for later) [20:21:33] I've once merged a rev with 10 changed lines across 3 or 4 files, and not a single one of them applied cleanly. I called it a 'somewhat creative manual merge' in my commit msg :) [20:23:34] neilk_: Did you write the TitleBlacklist API module? [20:23:40] Why is it an action= module not a query module? [20:23:43] no, Ian wrote it [20:23:49] Oh [20:23:55] It doesn't quite make sense the way it's written [20:23:56] I did review it though [20:23:57] Sort of minor [20:24:08] It extends ApiQueryBase but it's not a submodule of action=query [20:24:34] to be honest I have had similar problems when I write API modules that aren't exactly what the model expects [20:24:51] we're checking if a string would be a good title; not if an existing title has some problem. [20:25:04] so it doesn't make sense unless we make a new action, at least AFAICT. [20:25:08] Right [20:25:27] It should just extend ApiBase though [20:25:58] Doesn't seem to use any querybase stuffs [20:26:24] Yeah [20:26:29] (moving convo here) [20:26:33] k [20:27:22] hehe [20:27:24] PHP fatal error in /home/wikipedia/common/php-1.17/extensions/TitleBlacklist/api/ApiQueryTitleBlacklist.php line 40: [20:27:26] Call to undefined method ApiQueryTitleBlacklist::createContext() [20:27:28] Whoops [20:27:40] It uses RequestContext [20:27:49] *RoanKattouw fixes [20:30:09] neilk_: How do I trigger a negative on TitleBlacklist? [20:30:19] you mean, something bad? [20:30:25] How do I get it to say no to me [20:30:38] I tried using IMG0001.jpg and I tried adding the f-word [20:30:54] It uses the regexes here: http://test.wikipedia.org/wiki/MediaWiki:Titleblacklist [20:30:57] if you are using test [20:31:00] I am [20:31:28] Yay [20:31:30] http://test.wikipedia.org/w/api.php?action=titleblacklist&tbtitle=File:IMG0001hagger.jpg&tbaction=create [20:31:57] OK that seems to work fine [20:32:14] yes [20:32:28] Deploying TB site-wide [20:32:36] yay [20:33:21] oh crappity crap, I actually fixed that request context thing in my version. I forgot. [20:33:31] sorry about that. Didn't take you long i see [20:33:36] It's OK [20:33:41] It was just one usage [20:33:43] we just needed $wgUser [20:33:57] Incubator had more interesting bugs [20:34:15] The i18n thing I told you about was one thing [20:34:25] (exposed a bug in the het deploy changes) [20:34:42] The other thing was an issue with $wgConf->get() , a function for fetching a config var cross-wiki [20:35:00] Turns out that due to caching, it doesn't actually work for cross-wiki vars on a request that hits the conf cache unless you also call some other function first [20:35:06] Of course that only happens on WMF and nowhere else [20:35:23] Because the implementation of config cache is in CommonSettings.php, argh [20:37:36] Yay, TB works [20:37:37] http://commons.wikimedia.org/w/api.php?action=titleblacklist&tbtitle=File:IMG0001.jpg&tbaction=create [20:37:56] hey there is no jpegmeta in 1.17? still? [20:38:04] oh right, it's in 1.18 only IIRC? [20:38:13] We can pull it in if you need it [20:38:17] I think it was just under a different path [20:38:19] no, it's a nice-to-have. [20:38:24] it's not in the resources [20:38:26] at all [20:38:32] Huh [20:38:37] or am I crazy [20:38:41] No, you're right [20:38:49] I guess it did get moved but only after 1.17 [20:39:45] weird that seems like Cretaceous now [20:40:22] hehe [20:40:30] *RoanKattouw thanks neilk_ for enriching his vocabulary once moer [20:40:40] :) [20:41:39] Reading it I do recognize the name of the period, it's somewhat similar in Dutch [20:41:41] hm, undefined index: 'cpu' ? [20:41:47] wut [20:42:03] trying to run 1.17 locally. never seen this error message before [20:42:25] it's from Profiler [20:43:53] ok that magically went away when I ran the debugger :( [20:45:34] OK whatever [20:45:39] Not gonna be a problem on WMF [20:46:48] it's actually another issue now [20:46:58] something's wrong with how I defined mediawiki.uri.js [20:47:24] Meh, Ian reported a bug against his own code this morning and didn't fix it [20:47:25] http://commons.wikimedia.org/w/api.php?action=titleblacklist&format=json&tbaction=create&tbtitle=File%3A%09DSC123456.jpg [20:49:04] wrong directory... [20:49:28] *RoanKattouw proceeds to fix that bug [20:49:58] Oh, you reported it, not Ian, my bad [20:50:57] yeah that came up in testing but I figured it wasn't a big deal for now. [20:51:15] ok so Roan, here's something [20:51:38] ResourceLoader is complaining about something related to an RTL thing that someone else patched for me this month [20:52:08] Could you be more specific? [20:52:14] it is looking for jquery.arrowSteps.divider.png, but now we only have jquery.arrowSteps.divider-rtl.png and jquery.arrowSteps.divider-ltr.png [20:52:20] what is the right thing to do here [20:52:26] also, why has this never happened before? [20:52:36] was there a cache or something? [20:53:46] filemtime(): stat failed for /Users/neilk/Sites/1.17wmf1/extensions/UploadWizard/resources/jquery/jquery.arrowSteps.divider.png in /Users/neilk/Sites/1.17wmf1/includes/resourceloader/ResourceLoaderFileModule.php on line 373 [20:54:05] this is happening while it reads the CSS files, I think. [20:54:21] or maybe not, I can't quite figure it out. [20:56:25] Oh [20:56:35] Probably an image the CSS used to refer to but doesn't anymoer? [20:56:41] That stuff can get stuck in the DB I think [20:57:00] The right thing to do is ignore it [20:57:11] It's a bug that I need to investigate some time [20:57:33] But for now it's just log noise [21:00:22] I've been discussing that with trevor [21:00:33] unfortunately it's more than log noise it's preventing it from running [21:00:57] i'm trying to kill the caches now [21:01:50] How is it preventing it from running? Displaying the error? [21:02:00] TRUNCATE file_deps; [21:02:04] Ah [21:02:06] module_deps [21:02:44] Yeah, this makes sense -- we've killed the cache completely [21:03:04] why would module_deps not get refreshed when the module changes? [21:03:10] it should have been cleared and resanned [21:03:35] that worked [21:03:50] I said TRUNCATE module_deps; though. [21:04:03] TrevorParscal: It was stat'ing old files that the CSS didn't use any more and that didn't exist any more, but somehow were still in module_deps [21:04:11] Which, you're right, should update completely when you change the module [21:04:25] For some reason that doesn't happen; it doesn't purge old stuff at least [21:04:31] yeah [21:06:32] neilk_: Alright my TB stuff is all done. Where are you on UW [21:06:34] ? [21:06:51] RoanKattouw: testing functionality [21:06:54] real soon [21:07:10] BTW, are we admins on test.wikipedia? We need to be to test a feature or two [21:07:21] OK [21:07:29] I am [21:07:32] And I can promote you [21:07:47] yes, do so in the meantime [21:07:57] okay I need to fix some of Jeroen's hyper-modern code [21:08:09] to be old and stupid [21:09:39] User:NeilK? [21:11:10] neilk_: Are you User:NeilK on test? [21:11:25] I think so [21:11:39] yes [21:11:41] You now have sysop [21:11:49] Please log in and perform actions using https://test.wikipedia.org [21:11:57] Don't use http (for obvious reasons) and don't use secure [21:13:55] neither? [21:13:56] ok [21:14:20] ok, are you familiar with FormSpecialPage.php ? [21:14:35] ^ Roan [21:14:40] Jeroen is using it [21:14:52] I am nto [21:16:40] trying to determine what the right thing to do is [21:18:57] happy-melon invented this here http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86482 [21:19:09] made a base class and then went about merrily reinvented the wheel on a lot of pages. [21:20:08] brb [21:25:30] ok [21:25:49] RoanKattouw: any objections if I drag this library into 1.17? It's a pretty simple base class, doesn't depend on anything else. [21:26:00] Sure [21:26:17] 1.18 is close to getting to 0 new [21:26:20] doesn't seem to change the interface or depend on it [21:26:23] It's at like 95 now [21:26:30] So I have no scruples about messing up 1.17wmf1 even more [21:26:46] well, but then we're committing to messing up 1.18 too [21:26:56] No, because that class is in 1.18 [21:27:03] ok, np then [21:27:20] In your geology analogy, I'm taking my gun and shooting individual dinosaurs now and I don't feel bad because I know that meteor is coming [21:29:20] neilk_: what's the issue w/ FormSpecialPage? [21:29:33] JeroenDeDauw: the class doesn't exist in 1.17 [21:29:44] and we're trying to port it there so we can go live [21:30:08] I had just decided that we could probably just cram it into 1.17's SpecialPage.php [21:32:16] neilk_: probably [21:32:24] You can also add it as a new file [21:32:25] Damn, I thought it was in 1.17 already [21:32:40] You'll just have to add it to AutoLoader.php too [21:32:46] I know [21:36:05] ok, problem [21:36:13] $user is allowed to be null (more often?) in 1.17 [21:36:22] not as much in trunk (?) [21:45:44] neilk_: maybe just replace those w/ $wgUser? Doesn't really matter for this use case [21:46:08] yes [21:46:16] I'm finding all the cases -- it's whackamole [21:46:21] lots of getRequest or getContext [21:46:23] *RoanKattouw wonders how close the code is to being deployable [21:46:28] *neilk_ too [21:48:33] guh, is the old school equivalent of $webRequest->getQueryValues() just $_GET? [21:48:45] Yes [21:48:52] Except that it's not insecure [21:51:44] ok nine minutes to 3:00pm [21:51:48] how is your stamina Roan [21:51:58] heh [21:52:02] I'm a bit tired [21:52:15] It's midnight now, I got up at 8:30ish and didn't sleep much last night [21:52:27] Mostly because I slept 12 hours the night before to wake up at 2pm, so I screwed myself over there [21:52:59] I am trying to figure out the write way to create an HTMLForm now [21:53:02] right [21:53:23] it demands to have its own setTitle() call for some reason [21:53:41] You must call setTitle() on an HTMLForm [21:53:41] Backtrace: [21:53:42] #0 /Users/neilk/Sites/1.17wmf1/includes/HTMLForm.php(227): HTMLForm->prepareForm() [21:53:42] #1 /Users/neilk/Sites/1.17wmf1/includes/SpecialPage.php(1022): HTMLForm->show() [21:53:42] #2 /Users/neilk/Sites/1.17wmf1/includes/SpecialPage.php(578): FormSpecialPage->execute('wlm-zz') [21:53:42] #3 /Users/neilk/Sites/1.17wmf1/includes/Wiki.php(251): SpecialPage::executePath(Object(Title)) [21:53:43] #4 /Users/neilk/Sites/1.17wmf1/includes/Wiki.php(63): MediaWiki->handleSpecialCases(Object(Title), Object(OutputPage), Object(WebRequest)) [21:53:43] #5 /Users/neilk/Sites/1.17wmf1/index.php(114): MediaWiki->performRequestForTitle(Object(Title), NULL, Object(OutputPage), Object(User), Object(WebRequest)) [21:53:43] #6 {main} [22:09:16] ok, I'm not happy about giving up but I can't guaranteewhen this whackamole is going to end [22:09:20] ^Roan [22:09:22] heh [22:09:29] Maybe that means I should go to bed [22:10:00] I might be five minutes away or five hours [22:10:01] :( [22:10:16] sorry, I thought budgeting four hours to get this patch ready was enough, for some reason. [22:10:18] I'm gonna finish my e-mail queue [22:10:22] It's OK [22:10:39] I just wrote a BZ comment lamenting how we feel the pain of the distance between 1.17wmf1 and trunk every day [22:12:35] neilk_: Can't you just comment out the thing throwing the error? [22:12:53] Doesn't look like FormSpecialPage is accessing the title field anyway [22:16:05] JeroenDeDauw -- it's drawing a fieldset or something around it [22:18:41] Meh [22:26:41] RoanKattouw, JeroenDeDauw, I might have finally fixed it... sort of [22:27:11] anyone still awake in Europe? [22:27:26] we have unpublished commits in 1.17wmf1 :( [22:27:48] I'm still here [22:27:59] I went off the clock 7 minutes ago but I can deploy stuff if you need [22:30:26] it's committed now, but we should test it [22:30:37] Testwiki? [22:30:39] yes [22:30:49] Alright [22:30:56] Lemme look over the diffs real quick before I deploy it there [22:32:24] if it looks too sketchy, we can copy that state somewhere else and revert [22:32:36] I used to have an uploadwizard-deploy branch somewhere [22:33:17] + if ( is_a( $this->mWrapperLegend, 'Message' ) ) { [22:33:17] is_a(), really? [22:33:17] It's OK, but [22:33:27] We're not in 2006 any more [22:35:09] I used instanceof, but it complained for some other reason [22:35:18] like, bareword [22:35:23] I don't know why [22:35:28] Strange, it shouldn't have [22:35:41] that's what I thought too [22:35:55] does it not work with members? [22:35:58] It should [22:36:01] OK, code looks good [22:36:05] Gonna throw it on test now [22:37:12] I guess I'll have to add the tables, it'll probably explode in the meantime [22:38:24]