[03:44:02] it's more consistent with other MediaWiki extensions, and makes it look like mobile support is properly integrated rather than tacked on [03:57:58] TimStarling: Can I do something as simple as http://pastebin.com/v2cLdmgK [03:58:53] no, that's an XSS vulnerability [03:58:57] but you're on the right track ;) [03:59:23] xss is in title on $in? [03:59:36] both [04:00:08] but, I'll want $in to have html [04:00:22] first do: $in = $parser->recursiveTagParse( $in, $frame ); [04:00:48] then Html::rawElement( 'mpsection', array( 'title' => $param['title'] ), $in ); [04:00:59] okay, thanks [04:01:10] recursiveTagParse converts wikitext to something approaching HTML [04:01:45] but I think inventing custom elements is even more questionable standards-wise than inventing custom attributes [04:02:01] you don't know whether browsers will display the inside of it or just drop the whole subtree [04:02:05] so, like http://pastebin.com/UH7gnkbN then right? [04:02:18] yes like that [04:02:46] also it's a PHP notice if the title parameter is not given, you need to guard against that [04:03:20] $title = isset( $param['title'] ) ? ???. [04:03:24] yes [04:03:33] so, you don't like this approach [04:04:22] I'm thinking something more like return '' . $in . ''; [04:05:27] then you don't break standards [04:06:08] and note that comments can't be injected directly from wikitext, so you can be sure that any such comments in the output did actually come from your extension [04:06:20] good point [04:09:26] hmm [04:09:43] never mind, it should work [04:13:54] going for lunch [07:12:49] hi TimStarling [07:12:52] hi [07:14:07] so, I'm improving the logging system, but I've hit a problem with page histories. They contain copies of log entries, but it only allows plain text and some [[]] magic [07:15:45] so I have come up with few different solutions: 1) strip formatting of formatted log messages when saved to revision history and lose links 2) make log entries an exception and allow html for them in revision history 3) make the page history page query logging table too and show merged results 4) introduce new messages without special formatting for each log type [07:16:15] I'm leaning to 3), but what's your opinion? [07:17:03] yeah, 3 is interesting, but is it possible without changing the revision table? [07:18:00] TimStarling: it would need two different queries, (or changing the revision table to allow joins, but that's fifth option) [07:18:18] just log_title=whatever? [07:18:42] could work I guess [07:19:49] what do you mean with log_title=whatever? [07:20:54] there is log_page if I want to query logs with page id [07:21:22] and there's an index on it? [07:21:48] hmm I didn't check that [07:22:07] there is CREATE INDEX /*i*/log_page_id_time ON /*_*/logging (log_page,log_timestamp); [07:22:16] yeah, I have it in front of me now [07:22:43] that should be good, since we need to limit the results by timestamp, right? [07:23:14] yes [07:23:41] I wonder if it's used to display those log snippets that you get on edit pages [07:23:50] probably [07:24:03] or maybe those query by log type [07:24:33] there's no index for type and then page or title [07:24:41] or for page or title and then type [07:25:55] TimStarling: so I can go with making two queries, hacking the pager class in and out to join the results, and being very careful to keep the paging code working? [07:26:34] yes [07:27:06] I think it sounds like the best idea [07:27:10] okay, thanks [07:27:17] I'm not sure how much you'll have to modify the pager [07:27:41] I tried to make it fairly abstract so that things like this could be supported with a bit of work in subclasses [07:27:46] by overriding doQuery() [07:27:50] hmm [07:27:54] thanks for the pointers [07:28:01] it's not necessary for pagers to actually do database queries [07:28:30] because I have got the impression that it is quite unflexible [07:28:31] I think maybe I did one for Special:Allmessages that doesn't [07:28:42] and I think I once made one that combined multiple database queries into one result set [07:28:48] you did? [07:28:59] a different sort of combination though [07:29:12] if that is still somewhere around, it could be helpful [07:29:18] different time ranges that were joined end to end [11:01:51] TimStarling: hmm, I guess you're the only other person around who's be on the 1.18 call? [11:02:00] *RoanKattouw looks for a Reedy [11:05:21] *who'd be [11:11:56] Speak of the devil [11:12:03] RoanKattouw TimStarling: hmm, I guess you're the only other person around who's be on the 1.18 call? [11:12:05] RoanKattouw looks for a Reedy [11:12:25] I've told you about calling me the devil before ;) [11:12:31] Have you? I forget [11:14:32] Anyway, 1.18 meeting [11:14:40] Guess there's not much of a point if it's just the two of us [11:15:46] Looks like on the revision report we're still heading in the right direction [11:16:12] I feel like r91123 should count 10 times [11:16:33] hah [11:16:37] It's taking hours [11:16:57] *RoanKattouw generates rev report [11:18:22] Whoa it's going /up/ now [11:18:42] Things being tagged for 1.18? [11:19:20] I think so yeah [11:22:21] is there any code excerpt available on our servers how to cycle per all languages of given wiki family to query very simple direct select for one row? [11:23:02] In PHP or bash? [11:23:24] php [11:29:12] Is Timo on the engineering alias? [11:31:35] Yes [11:31:38] Should be, at leat [11:32:39] Hmm, in PHP... [11:32:55] I'm not sure offhand how you'd get all wikis in one family as opposed to all wikis [11:33:26] But given a wiki, you can do $dbr = wfGetDB(DB_SLAVE, array(), 'cswiktionary' ); $row = $dbr->selectRow( ... ); [11:33:38] Then you have to do some magic to clean up the DB conn too, let me look that up [11:33:47] SiteMatrix? [11:33:57] Oh here we go [11:33:58] would need a bit of work [11:34:03] $lb = wfGetLB( $wiki ); [11:34:05] $db = $lb->getConnection( DB_MASTER, array(), $wiki ); [11:34:12] Do stuff with $db [11:34:14] $lb->reuseConnection( $db ); [11:34:28] (stolen from maintenance/wmf/clearMessageBlobs.php) [11:35:33] ah, shoot. fool me, i forgot to say that i meant standalone code. not dependant on mw [11:36:11] but thanks anyway [11:36:21] i'll utilize that one elsewhere too [13:01:26] RoanKattouw, mind re-running the revision report? [13:01:44] After I finish this review [13:01:54] cheers [13:03:04] Wut [13:03:10] 70/45/25 [13:03:21] Oh, that's probably because Siebrand tagged all that Narayam stuff [13:03:26] yeah [13:03:38] *RoanKattouw untags [13:05:20] Fatal error: Call to a member function getNamespace() on a non-object in /home/wikipedia/common/php-1.17/includes/job/JobQueue.php on line 309 [13:06:50] 60/35/25 [13:07:01] From 60/38/22 [13:08:27] I wonder if it's worth bothering to try and defend against that [13:34:56] RoanKattouw: sorry, was busy [13:35:14] do you need anything from me? [13:36:44] Nothing in particular right now [13:36:59] There was supposed to be a 15-minute call 2.5 hours ago, but I was the only one that showed up [13:37:03] That's why I pinged you at the time [13:37:34] yeah, I know [13:37:46] but if we actually had that meeting, I would have asked you if you needed anything [13:38:03] so I'm asking now instead [13:38:30] heh, OK [13:38:49] So, about that Squid purge breakage thing, how did you find out [13:39:06] Like, is there some place you can see the purges MW sends to Squid? [13:41:03] well first, people came to #wikimedia-tech and complained about images not being purged [13:41:07] so I ran tcpdump [13:41:34] Ah [13:42:00] I didn't see it there initially, there's a lot of different callers of SquidUpdate::purge() [13:42:12] then someone reported another bug that was caused by protocol-relative URLs [13:42:27] i.e. total breakage of OggHandler [13:43:06] so I worked it out eventually [13:43:08] Yeah, I saw that too -- I didn't see where it'd break, though. I tracked the path of $url in trunk and didn't see it used anywhere where it would break things [13:45:04] Anyway, I fixed the SquidUpdate issue by setting $wgInternalServer in CommonSettings.php [13:45:35] And I wanted to backport your OggHandler fix to trunk and 1.18 but after reading the code I don't understand what would be broken by using protocol-relative URLs in that particular location [13:46:37] two things [13:46:43] 1. it's not using a protocol relative URL there [13:46:45] 2. java [13:46:53] reportedly [13:46:59] Grah @ 2 [13:47:23] if ( substr( $this->videoUrl, 0, 4 ) != 'http' ) { [13:47:23] global $wgServer; [13:47:23] $url = $wgServer . $this->videoUrl; [13:47:31] this does not output a protocol-relative URL [13:47:43] it outputs //commons.wikimedia.org//upload.wikimedia.org/something [13:47:43] That depends on what $this->videoUrl is [13:47:59] Ah, yes [13:48:19] it was the same with SquidUpdate [13:49:31] You mean SquidUpdate produced stuff like //foo.wm.o//bar.wm.o/baz? [13:49:35] yes [13:49:39] WTF [13:49:45] $server = $wgInternalServer !== false ? $wgInternalServer : $wgServer; [13:49:47] if( $url !== '' && $url[0] == '/' ) { [13:49:48] return $server . $url; [13:49:50] } [13:49:51] return $url; [13:50:06] Oh [13:50:07] Rigt [13:50:09] D'oh [13:50:13] $url[0] == '/' [13:50:29] So my "fix" still left it broken [13:51:20] OK, this is nastier than I though [13:51:24] I will reinstate your live hack [13:51:41] you mean you deployed an alternative fix and didn't test it? [13:52:50] I did. I was too confident of my understanding of the problem [13:53:07] My code would've output http://foo.wm.o//bar.wm.o/baz instead [13:53:58] I guess wfExpandUrl() needs PROTO_INTERNAL with behavior similar to that of PROTO_CANONICAL [13:58:14] I'm going to repeat what I said about OggHandler on CR [13:58:14] TimStarling: http://pastebin.com/8ngTeJ2i [13:58:18] for the record [13:59:55] OK [14:00:07] I am opening tcpdump on a text and an image Squid [14:00:25] So I can get a look at the HTCP purges coming in right now and can see a before and after when I deploy that diff [14:01:04] your patch looks ok [14:02:37] Replied on the OggHandler CR, two minor concerns [14:09:25] TimStarling: Hmm, how do I find these packets? tcpdump udp mostly finds outgoing packets to the Squid logging aggregator on emery. tcpdump udp and dst sq80 finds things that I think are DNS packets [14:10:09] tcpdump dst host 239.128.0.112 [14:10:30] Oooh [14:10:31] Of cousre [14:10:40] tcpdump dst host 239.128.0.112 -c400 -A -s1500 | grep upload\\.wikimedia\\.org [14:10:53] -C3 [14:11:01] Sweet, thanks [14:11:12] Yeah, of course it's multicast so the dst != the host's IP [14:12:08] I originally used dst port 4827, but that was picking up HTTP packets with that ephemeral port [14:12:11] dst host works nicely [14:12:45] dst port 4827 and udp would've worked, probably [14:16:23] *RoanKattouw throws stuff at svn merge [14:25:38] OK that seems to have worked [14:25:52] root@sq71:~# tcpdump dst host 239.128.0.112 -c400 -A -s1500 | grep '//' | grep -v 'http://' | wc -l [14:25:53] 0 [16:35:07] someone tell robla when he comes on that I don't think I can make the call in 1/2 hr [16:44:37] someone tell robla when he comes on that I don't think I can make the call in 1/2 hr [16:45:04] nice job [16:45:25] lol [16:45:27] I wonder if he got the message [16:45:37] someone tell robla when he comes on that I don't think I can make the call in 1/2 hr [16:45:50] k....thanks for the warning [16:46:00] (stoopid office wifi) [16:46:23] unbelievable that after so many different configurations it still is unreliable [16:46:37] robla: Just now, after a report on IRC I discovered this 1.17 snafu: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/87498#c17746 [16:47:40] Apparently we released 1.17 with a broken ForeignDBRepository, even though someone tagged the fix for 1.17, but I untagged it because the rev was past the branch point (without noticing it was MFTed) [16:54:59] robla: actually looks like I can call in, but I'll be muted the whole time since I'm in a coffee shop [16:55:15] that's fine [16:55:38] I'm thinking of shifting this call 30 min earlier starting tomorrow. [16:55:52] it's also not a great time for Reedy [16:56:35] robla: maybe I can bring up the release blocker bugs at the next call? [16:57:03] hexmode: how many are there? [16:57:31] 4 https://bugzilla.wikimedia.org/show_bug.cgi?id=29068 [16:58:02] 3 more on https://bugzilla.wikimedia.org/show_bug.cgi?id=28425 [16:59:16] https://bugzilla.wikimedia.org/show_bug.cgi?id=30612 is definitely not a deployment blocker [16:59:20] It's a prototype config issue [17:09:27] robla: RoanKattouw: etherpad links you are looking at? [17:09:38] http://etherpad.wikimedia.org/118deployment-scrum [17:09:44] http://etherpad.wikimedia.org/118deployment [17:14:40] raindrift: Today's UW deployment is just the comma fixes and nothing else? [17:17:09] raindrift: Today's UW deployment is just the comma fixes and nothing else? [17:17:19] yes, that's right. [17:17:28] sorry, wrote back, but my client had, um, issues. [17:17:32] I saw [17:25:30] roan: let me know when you're ready to test. i'll go pull up a vm (this bug only shows up on windows) [17:25:47] raindrift: Should be on test.wp.o now [17:26:00] awesome. checking it out. [17:28:19] Hm. new error that I didn't get in dev. just a minute... [17:37:20] oh, hm. it seems maybe the RL cache hasn't cleared. how long does that take? [17:37:52] 5-10 min [17:38:15] hm. it's been 10 minutes. lemme make sure it's not a local cache issue. [17:38:17] RoanKattouw: we did a debug=true and got the same errors that raindrift saw before he fixed them [17:38:34] the usual stuff that IE says when there are trailing commas and some other stuff. [17:38:37] hmm [17:39:03] Sorry can't help much, going to an interview in a few min and have to eval some stuff. [17:39:11] not local caches... [17:39:46] How do you reproduce, just by hitting UW? [17:39:51] Hmm, let me sync the test box [17:40:09] yeah. hit uw. add a ?debug=true if you want to see the actual informative errors. [17:40:26] no error in chrome. in ie6/7, you'll get an endless spinner and errors. [17:40:39] *RoanKattouw fires up VM [17:48:29] raindrift: UploadWizard WFM on testwiki in IE8 [17:48:32] Oh, IE6/7 [17:48:34] Crap [17:48:36] I don't have a VM with those [17:48:56] can you get to sfo-virtual1-xp-ie7 with RDP? [17:49:10] Probably not [17:49:14] I am not in the office [17:49:28] mm, yeah. they're on nat'd addresses [17:49:50] Yeah, they have 192.168.NNN.NNN addresses [17:50:23] well, you can let me know what you were going to do, and i can do it. [17:50:32] I was just gonna test it [17:50:45] Visit UW on test in IE7 and see what happens [17:50:53] You could try it again with Ctrl+F5, I guess, I synced the test box more than 5 mins ago [17:51:15] yep. still broken. [17:51:57] Grah [17:52:03] I'll just deploy the fix site-wide [17:52:30] if you want.. i'm looking now to find the actual code change so you can see if it shows up using a reasonable browser. [17:52:35] "Sorry, we could not find a tutorial in your language. The English one is shown instead." [17:53:13] Hey guys, just a short question before the triage begins: will we be discussing only the bugs selected by Mark or all the UW bugs that are brought up? [17:53:37] raindrift: Done, fix should be in production in 5-10 mins [17:54:09] strainu: i'd like to focus on the high-priority bugs, but if there's something you're really into working on, do it. [17:54:19] roan: awesome. thanks! [17:54:39] roan: i'm going to grab a bagel while that happens, will test shortly. [17:56:48] raindrift: what about Unprioritized bugs? does that mean that nobody has gone through them or they're just considered unimportant? [18:03:57] Is the UW bug meeting here? [18:04:13] I believe so [18:05:38] Right [18:05:52] strainu: many of them have been reviewed, but probably not all of them. [18:06:20] strainu: though, i have seen people prioritizing them recently [18:06:26] so what should I do exactly, put the bug in Etherpad? [18:06:33] sorry, it's my first triage :) [18:07:03] I'm not sure I can actually help with patches, but I ugs recentlywent through quite a lot of UW b [18:07:04] hexmode: Don't you have a triage to lead here? [18:07:19] i'm not entirely sure. it's my first triage also. :) [18:07:28] Oh, d'oh [18:07:31] 19:00 UTC [18:07:34] That's an hour from now [18:07:35] RoanKattouw: yeah [18:07:37] :) [18:07:42] indeed. [18:07:56] had me scared :P [18:08:59] but please see the etherpad in the meantime... trying to sort out the bugs [18:09:06] Oh, the bug thing is only in an hour? [18:09:10] Meh [18:09:36] *JeroenDeDauw goes back to Survey [18:09:37] JeroenDeDauw: I thought 2, but don't have a UTC clock handy [18:09:56] yes, 19:00 UTC is in an hour :) [18:10:18] good thing I'll be ready :) [18:10:21] It's just here on IRC right, ie no calling involved? [18:10:28] hexmode: perhaps you can answer my question to raindrift ? [18:10:35] JeroenDeDauw: yes [18:10:47] strainu: 5min [18:10:55] then I can [18:11:01] ok :) [18:11:03] hexmode: ok :) [18:11:16] Time to go to the local hackerspace then [18:14:34] strainu: could you repeat your q? [18:14:51] *hexmode checks scrollback just in case [18:14:54] Roan: seems like it's still broken on commons, but with another, new error. Does debug=true work on live commons? [18:15:12] what should I do if I want to discuss a bug that is not in etherpad? [18:15:20] and it's marked as unprioritized [18:15:41] strainu: if it is unprioritized, then I haven't seen it yet [18:15:50] raindrift: It should, yes. What's the error? [18:15:50] I've fallen behind in the past week [18:15:53] :( [18:16:08] access is denied, line 5114 [18:16:10] strainu: so yes, paste bug # and summary into the etherpad [18:16:17] raindrift: What, what?? [18:16:19] ok, thanks [18:16:21] Is that all you get? [18:16:23] (but ie7 doesn't report which file it's talking about, which makes debugging quite mysterious) [18:16:23] strainu: http://etherpad.wikimedia.org/BugTriage-2011-09 [18:16:33] raindrift: hmm let me try something [18:16:42] hexmode: got it, will paste it [18:18:15] I made a new section for WLM bugs, and I will search for other such bugs, just in case [18:18:23] perhaps multichill knows some more [18:18:30] :) excellent [18:18:39] raindrift: I tried IE8 in IE7 mode (not compat mode but actual IE7 mode), but couldn't reproduce on test [18:18:49] they're special in the sense that a fix needs to be done and pushed ASAP, otherwise it's useless [18:19:03] in 2 weeks time it won't matter much [18:19:13] raindrift: Where does the bug occur exactly? Opening UW, in a specific step, ... ? [18:19:27] Oh, heh, debug=true breaks for me too [18:19:39] Object expected [18:19:54] line? [18:19:59] Object expected UploadWizardPage.js, line 17 character 2 [18:20:10] oh. that's new. [18:20:13] oh, wait. no. [18:20:14] that's not. [18:20:15] Probably a loading order bug [18:20:20] Due to debug mode [18:20:29] It worked fine in non-debug mode, I even uploaded a file [18:20:40] Again, this is IE8 in IE7 mode, so probably not quite the real thing [18:21:58] RoanKattouw: since I figure you're gonna be around: I've got to walk through the rain and then drive home. Please let people know that I haven't forgotten them if I'm not back in 40 min [18:22:22] OK [18:23:19] yeah. so, with debug=true in actual ie7, I get "expected identifier, string, or number" on 907 and 286 (note, however, that these are errors in separate files). These are the errors I fixed, and when fixed they made the Object Expected error go away as well. [18:23:56] with debug=false, I get Access Denied on line 722, which isn't an error I ever got in my dev environment. I'm curious if it's caused by the same problem, though. [18:24:24] (err, not line 722, line 4 character 722) [18:24:48] anyway, those first two errors should be corrected. lemme check with Chrome and see if they are, in fact, gone. [18:27:48] yeah, the js being returned from the server (on test) is correct. [18:32:26] okay, this is super weird. [18:34:08] when I load UW in Chrome on my machine, I see the correct file (mw.UploadWizard.js line 904 has no comma), but when I load the same page using an ie6 VM with MS Script Debugger (that I haven't used to load testwiki yet today), I get the incorrect mw.UploadWizard.js, with a comma on line 904. [18:37:37] Oh, I see. IE7 doesn't clear JS from its cache. It must be done by hand. Got it. [18:40:13] Pfft [18:52:47] Hey brion, what ever happened with that inline JS editor for MediaWiki textareas that you put together? [18:53:42] kaldari, http://www.mediawiki.org/wiki/Extension:CodeEditor [18:54:35] Thanks! Is that deployed anywhere, btw? [18:55:12] it's avail in gadget form on mediawiki.org [18:55:25] but i've not gotten around to pushing anyone to deploy it fully :) [18:56:11] It would be a nice gadget to have on meta as well - for the fundraising banner coders [18:56:32] *nod* [18:56:35] i'll copy it over [18:56:44] we have silly JS errors in the banners on a regular basis [18:56:58] thanks! [18:57:03] it might not trigger automatically on those though. does it show the regular edit toolbar? [18:57:24] no it's actually just a textarea [18:57:38] maybe I could hack some of your code into CentralNotice for it [18:57:42] ok then we'll need to tweak it a little extra probly :D [18:58:02] or vice versa - hack the gadget on meta [18:58:06] yeah [18:58:32] let me know once it's copied into meta and where it lives [18:59:32] . [19:00:39] aww i think i lost my privs on meta, it won't let me edit the .js page :D [19:01:18] kaldari, just copy over the bits linked from http://www.mediawiki.org/wiki/Extension:CodeEditor#Gadget [19:01:52] most of the guts are loaded from a copy of the extension living on toolserver [19:02:17] so if you can just add code to the loader stub in the gadget then feel free :D [19:02:29] you can probably also just add some code to the gadget to do the setup on the other forms [19:06:39] ok... rain made me late [19:06:43] but here I am :) [19:06:46] shall we begin? [19:06:48] hey! [19:06:51] yes, let's. [19:06:53] http://etherpad.wikimedia.org/BugTriage-2011-09 [19:07:17] who is Ian here? [19:07:27] that's me. [19:07:33] just changed my name in the etherpad for consistency [19:07:40] :) [19:08:04] good, so, first section [19:08:12] (about 10min/section) [19:08:39] these all seem like bugs that interfere w/ functionality [19:09:37] (btw light yellow and light purple are erik) [19:10:28] also, neil will be joining us in a minute [19:10:32] raindrift: any comment on those under "core"? [19:10:34] kk [19:11:02] is mdale here? [19:11:03] we have a few bugs with the language parser at this point. we should probably categorize them together. [19:11:07] hello [19:11:14] hi, neil. [19:11:16] neilk_: hey! [19:11:35] raindrift: makes sense [19:12:25] I don't see the others in here, though??? lemme go look around. [19:13:55] neilk________: strainu is here [19:14:06] JeroenDeDauw: hey! [19:14:22] neilk_: strainu is WFM, I think [19:14:22] neilk_: were you looking for me? [19:14:36] WFM ? [19:14:42] WLM I think :P [19:14:44] WLM [19:14:44] you mean WLM [19:14:46] sorry [19:14:57] WFH (?) [19:15:00] heh [19:15:08] Wiki (really really loves) monuments [19:15:59] yeah, so after all WLM only has 1 bug :) [19:16:03] hexmode: hey [19:16:04] mine was a duplicate [19:16:13] hrm... don't know why #30665 wasn't in there [19:16:15]