[00:00:12] Bawolff here ? [00:00:17] 03(mod) Shared repositories support for Special:WantedFiles - 10https://bugzilla.wikimedia.org/6220 +comment (10krinklemail) [00:03:31] I was just wondering the same thing actually [00:08:01] I think the answer is no [00:11:39] ...probably the same answer for preilly [00:14:18] New code comment: Krinkle;

+ -moz-opacity: 0.25;

\ This was last supported in Mozilla 1.7 (Firefox 0.9) and removed i; [00:18:33] New code comment: Krinkle; jQuery uses zoom: 1; to do so ([https://github.com/jquery/jquery/blob/f724bc6c921378b82; [00:27:48] New code comment: Krinkle; Yep, we need to match tfoot and thead as well. Using the * instead of [00:29:12] why is XML so complicated? [00:29:52] it's meant to be a simplified version of SGML, right? [00:31:32] New code comment: Krinkle; Reviewed JS/CSS part. Not marking OK per the PHP changes.; [00:34:30] TimStarling: Let's hate XML together [00:35:01] I've wished many times that the API didn't have XML output, because XML is so inflexible compared to e.g. JSON [00:36:03] RoanKattouw: Hi [00:36:15] Ohai [00:36:42] RoanKattouw: Nike raised an interesting bug in the client loader for RL that I experienced a few times as well but neglected at the time. [00:36:58] RoanKattouw: mw.loader.using('not exist', .., ..) calls the OK callback [00:37:11] I know why, but it's complicated. [00:37:26] heh [00:37:30] I'm not surprised [00:37:51] load() handles this differently, though, doesn't it? [00:38:25] RoanKattouw: the internal resolve() is part 1 of the 2-part problem. [00:38:45] resolve returns an empty array for an undefined module, but otherwise an array with all dependencies including the module itself [00:39:06] Right [00:39:11] I think I can imagine what part 2 is [00:39:15] that should return [module] instead of [] probably. So that the loader (which does support fixing undefined modules) actually gets it [00:39:25] for each module in [] : is module present? [00:39:26] if I change that, we get an exception [00:39:48] Right [00:39:51] in mw.loader.work where it requests .source property [00:39:54] Is that the same behavior as load? [00:40:01] I don't know about .load() right now [00:40:13] There's a third case too [00:40:19] Valid module with invalid dependency [00:40:27] loaded through either load() or using() [00:40:42] mw.loader.work checks if it's undefined but only in the first part, later it doesn't' check it [00:40:46] if I fix that we still have a problem [00:40:47] 03(NEW) i18n for special property (German) - 10https://bugzilla.wikimedia.org/33463 normal; MediaWiki extensions: Semantic MediaWiki; (mediawiki) [00:40:51] (I guess they'll probably at least behave the same in that case thanks to resolve() ) [00:40:57] the server request wil do mw.loader.state('not exist', 'missing') [00:41:12] but .state() only sets the state, it doesn't handle the waiting callbacks [00:41:24] Hmm, so the loader will request the module from the server even if the loader believes it doesn't exist? [00:41:35] so in my working copy I have it fixed to the point where everything goes already and the module is instantly registered with state "undefined" (which is a valid state) [00:41:42] but then neither callback of using() is called [00:42:12] RoanKattouw: Well, we should probably fix cases like invalid dependency and undefined requested module client side, yes. [00:42:38] Ideally they'd all behave the same [00:42:59] but, there is still a case where the client thinks its defined but it no longer is on the server. We should not depend/rely on the server giving mw.loader.implement calls which handles the callbacks further [00:43:03] I predict invalid dependencies will at least behave the same regardless of whether the depending module is loaded with load() or using() [00:43:11] Yes, that's true [00:43:18] if the server gives state() instead of implement() (which it does for missing modules) - we need to handle callbacks there too [00:43:22] But it seems the loader is trying handle the inverse as well, which is unreasonable [00:43:39] The client-side loader must not try to load modules it believes to be nonexistent, that's asking for trouble [00:43:41] it supports it in some parts but assumes the invert in other parts [00:44:01] Even if the module has magically come into existence in the meantime, the loader won't have the dependency metadata so it can't be sure it loaded it properly [00:44:05] RoanKattouw: Right now it doesn't but that's not thanks to mw.loader.work but due to a bug closer to the public calls [00:44:37] Let me rephrase that then [00:44:43] RoanKattouw: True, so we should not support loading of modules registered server side after the page is loaded, but do support the other case, were modules are no longer existent after the page is loaded [00:44:50] Yes [00:44:56] That case should be supported [00:44:57] alriighty [00:45:17] The client must be able to deal with a 'missing' response even if it believes the module exists [00:45:44] yep, so we need to implement mw.loader.implement()-like success/error handling in .loader.state() [00:46:06] Yeah [00:46:07] or change server output to output a common point in loader for all cases [00:46:27] mw.loader.serverresponse or something [00:46:48] .state() is really just to set the state and register if needed. [00:47:00] If we could keep the server-side API the same that'd be nice [00:47:12] I agree it makes more sense to make a serverreponse() function [00:47:30] Hmm I guess the client-side API would need to be backwards compatible then [00:47:59] should it ? [00:48:02] The last thing I need is for cached responses to wreak havoc on the site due to incompatibilities right after deploying this change [00:48:08] ah, right. [00:48:14] as well as cross-wiki stuff [00:48:20] Yeah that too [00:48:21] which we'll have now thanks for RL2 [00:48:29] Well, not in production anywhere [00:48:32] true [00:48:34] not even in trunk [00:48:41] yeah :P [00:48:41] But this shouldn't be hard to pull off [00:48:44] no [00:48:47] we do have it in trunk [00:48:52] We'll just keep implement and state the same, and add a layer [00:48:53] addSource etc. [00:49:05] Then cached stuff will bypass the serverResponse() layer but that's fine [00:49:08] that might even be in 1.18, otherwise in 1.19 [00:49:16] that is, it won't regress [00:49:28] Oh, right, that stuff is in trunk [00:49:35] Yup [00:50:49] Gotta go in a few minutes [00:50:57] Let's pick this up later this week [00:51:13] Yeah [00:51:30] 03(mod) Global account not appearing on Special:GlobalUsers - 10https://bugzilla.wikimedia.org/30185 (10Mark A. Hershberger) [00:51:45] hexmode: https://www.mediawiki.org/wiki/Talk:Code_review_tags#x.22important.22_tag_10302 [01:01:58] * varnent pondering why MW.org's Mbox doesn't fill screen properly [01:10:20] 03(mod) Renaming user causes conflicting usernames in deleted file histories - 10https://bugzilla.wikimedia.org/33452 +platformeng (10Mark A. Hershberger) [01:10:41] 03(mod) Annotation greek part-of-speech - 10https://bugzilla.wikimedia.org/33453 (10Mark A. Hershberger) [01:20:17] *sigh* why must MobileFrontend be so messed up [01:21:50] Dantman: I think I tried to point that out. [01:22:08] But mobile is some kind of strange world. [01:22:29] Wanted to fix the messed up url handling. [01:22:51] Wanted to make it so I could hook in and add a mobile ad to the sites that have desktop ads. [01:23:04] And I end up stuck at the device detection point. [01:23:20] Actually the domain detection point as well... that doesn't seam to work either [01:24:14] "There is no device with id [generic] in wurflbool(false) " [01:33:36] https://www.mediawiki.org/wiki/Extension:UserExport [01:33:49] "User Export is a very simple extension to generate a CSV file with the user name and email of all Mediawiki users." [01:33:56] WHY [01:34:31] johnduhart_, CSV is the way forward [01:34:36] oh good lord it uses permissions [01:35:20] I have no idea what the context here is, but CSV being the way forward scares me ;) [01:35:45] hehe [01:36:00] bawolff stop being so closed minded [01:36:07] anyone notice my current rampage? https://www.mediawiki.org/wiki/Special:RecentChanges [01:36:18] if ( $site == 'wikipedia' ) { [01:36:25] $wgMobileFrontendLogo = '//upload.wikimedia.org/wikipedia/commons/1/16/W_logo_for_beta_test_of_Mobile_Frontend.gif'; [01:36:30] There's bugs about that [01:36:31] * Dantman rolls his eyes [01:37:00] Dantman: What? [01:37:07] johnduhart_: MobileFrontend [01:37:18] I know, what about it? [01:37:28] Reedy, at the very least, unix style semi-colon deliminated files don't have the varrying weird escaping rules that most csv files have [01:38:31] hmm, looks like i missed Krinkle [01:38:59] Tim was also looking for you [01:40:07] johnduhart_: ...WMF config hardcoded into the middle of an extension [01:40:24] Reedy, any idea what about? [01:40:59] Dantman: Well I had assumed that snippet had come out of CommonSettings.php [01:41:04] * varnent has had his Xbox account hacked…argh… [01:41:21] If that's the case then yeah that's really bad [01:41:23] johnduhart_: ;) Nope, right out of the bottom of MobileFrontend/MobileFrontend.php [01:41:25] bawolff, he commited some SVG code modifications around the same time [01:41:42] varnent: lol consoles [01:41:50] johnduhart_: ;) Which btw, is a lot of body code in the boilerplate setup file [01:42:02] oh right, i have a follow up email about merging something in to 1.18wmf1 that he did. possibly about that revision [01:42:27] johnduhart_: they're my not-so-secret addiction [01:42:29] johnduhart_: Yay {{Extension code in wiki}} [01:42:46] * johnduhart_ high fives Dantman [01:42:53] Code in wiki MUST DIE [01:43:40] Oh GOD no... I should have never clicked on a random extension link in the RC list https://www.mediawiki.org/wiki/Extension:BuddyPressActivity [01:43:46] Dantman: I agree, that file is huge [01:43:56] * johnduhart_ looks at preilly [01:44:09] * varnent is eager to start moving some extensions from wikicode to repo [01:44:27] varnent: meh, all the ones I tagged are crap [01:44:29] Most of them [01:45:10] Do we really need to move crap unmaintained extensions into svn so they can rot even more? [01:45:30] Heh, nooo [01:45:35] Ones that are useful [01:45:53] and work [01:46:24] Check, and mate... small one, but I see a usable SQL injection vuln [01:46:38] Do we have a template for that? [01:46:39] well that does raise an interesting question - what do we do with extensions that aren't great - aren't really worthy of repair - and are posted as wikicode - do we just leave them as wikicode? archive them as subpages? bury them? delete them? [01:46:52] {{DONOTUSE}} [01:47:24] Dantman: http://www.mediawiki.org/wiki/Project:WikiProject_Extensions/Templates [01:48:11] nope [01:50:20] I mean we can tag the pages to let folks know not to use extensions with wikicode posted - especially once the good ones have been imported to the repo - but it seems like leaving the code as wikicode even on incompatible, obsolete, etc. extensions would be displeasing - or is it just not a worry with those unmaintained ones? [01:50:48] also - is there a reason we keep the wikipage for those extensions live? should we be replacing them with a tag saying "this extension is obsolete and archived in revisions" [01:51:10] The politeness of not deleting something that someone wrote? [01:51:16] code that is [01:51:41] One of these days I wish for a real extension repo. One where we can actually 'archive' something. [01:52:22] This is the most useless extension https://www.mediawiki.org/wiki/Extension:PasswordProtected [01:52:33] "In page put in: the password for the page" [01:52:35] Dantman: do you think keeping the page live and allowing access to revisions - maybe linking to the revision link for the last full page - rather than outright page deletion - is respectful enough? [01:52:44] "Despite these password, if the user clicks to the View Source tab, he can see the code of the page and with it the password and the content." [01:53:56] Aaaagh... [01:53:59] It uses raw sql too [01:54:07] I know!! [01:54:32] varnent: I think for really old extension a blank with a template about being obselete and unmaintained with a link to the last revision is enough [01:55:05] johnduhart_: I tend to agree - I feel like it's a fine line between respecting developers and leaving things up forever to only cause confusion for new devos or sysadmins [01:55:19] I now more then ever wish for a MediaWiki 2.0 so we can say "Nope, all those junk shit extensions that are completely horribly written..... those are no longer compatible, time to rewrite them into real extensions..." [01:55:23] clean slate. [01:55:31] Dantman: fair point [01:56:02] I'll also work on a template for nominating an extension either for repo conversion or archiving - give original developer a couple weeks to speak their mind if they so desire [01:56:20] I think that'll cover our bases on respecting people's wishes and such [01:56:22] Heh wait... [01:56:40] johnduhart_: ;) addMessage... I don't think that extension is even compatible with current stable [01:56:43] lol [01:56:49] lol [01:56:52] saw that too [01:56:56] {{incompatible}} [01:57:21] I also like the attempt at internationalization [01:57:36] lol - just bury the extension by adding so many warning headers - they take up 50%+ of the page real estate :) [01:57:43] 03tstarling * 10/branches/wmf/1.18wmf1/includes/media/SVGMetadataExtractor.php: MFT r107359: fix Adobe Illustrator SVGs presumably broken by a PHP upgrade [01:58:36] This should be a core feature if it's not already, would be simple to do too https://www.mediawiki.org/wiki/Extension:Minimum_Name_Length [01:59:03] * Dantman snickers at his perhaps overboard warning message [01:59:13] "Vulnerable to SQL injection attacks, because it passes user input directly into SQL commands. This may lead to user accounts being hijacked, wiki content being compromised, private data being leaked, malware being injected, and the entire wiki content being erased, among other things." [02:01:58] I recall brion describing a worse case scenario being the wiki getting taken over and used to host child pornography [02:02:06] lol [02:02:11] !worstcase [02:02:11] Generally, the worst that can happen is that someone compromises your site, steals your data, deletes it and replaces it with kiddy porn. Then they start a spam service on your server advertising the kiddy porn to twenty million email addresses, daily. Then your home gets raided, you get fired and your wife leaves you. Then you get killed in your sleep by ninjas. [02:02:25] oh I guess it was mw-bot [02:02:46] Oh... but who knows who told that to mw-bot ;) [02:07:07] johnduhart_, just do it [02:07:19] Can almost copy paste the code to around the point the hook is called [02:07:30] there seems to be a lost opportunity in that scenario about prisons…but the ninjas works I suppose... [02:07:42] harest part is getting the message or 2 moved [02:07:58] Reedy: I'm in the middle of "writing a research paper" [02:08:04] note the quotes [02:08:10] haha [02:08:13] Procrastination ftw [02:08:28] It's amazing how productive one can be when there's other stuff needing doing [02:08:54] I know right [02:08:57] Hell, we could just keep minnamelength-error key [02:09:26] Are we tagging these simple "merge to core" esk ones somehow? [02:09:47] Not at the moment, should be a simple template to make [02:10:11] Or just list them somewhere [02:10:23] Awwww... that's no fun... baddly written extension using program execution and the potential code execution vulnerability isn't plain and easy to use? [02:10:52] It makes things 'so' much simpler... [02:11:03] $wgMinimumUsernameLength = 10; should go to 0 also [02:11:16] * Dantman kicks Reedy [02:11:20] Well actually one [02:11:31] Do we allow zero length names anyway? [02:11:33] I don't have to wrack my brain trying to find the edge case where the injection works... just to prove a point [02:11:55] I presume we don't [02:12:41] 1 would be fine [02:12:46] I might jfdi after sleep [02:12:54] which i'm currently procrastinating from [02:14:01] johnduhart_, I especially like the changelog for that extension [02:17:08] Dantman: I think the biggest problem with MobileFrontend is that it's now apparently trying to rewrite large portions of MW. [02:17:21] Like login code and shit. [02:17:27] Rather than just doing CSS shit. [02:17:37] I don't really understand it at all. [02:17:47] But nobody else seems to be paying attention or care. So.. shrug. [02:19:03] https://www.mediawiki.org/wiki/Special:Code/MediaWiki/104128#code-comments [02:19:30] I agree [02:20:00] It seemed so illogical to me that I figured I was just misunderstanding. [02:20:19] I don't understand mobile development. [02:22:33] Sadly... I fear that the simple answer is this... MobileFrontend is being authored by someone who hasn't had enough experience writing other MW code. [02:23:05] Right. But the point I odn't get is that Wikimedia has already done this once. [02:23:10] Except they did it in Ruby instead. [02:23:30] I dunno. It's painfully illogical to me, so I just try not to think about it. ;-) [02:23:52] In other topics... [02:24:18] I wish we had a Template:CRAP so I could just shove {{CRAP}} at the top of half of these extension pages [02:24:55] Dantman: We do have something kind of similar - ?action=delete :P [02:25:00] lol [02:25:19] It'd take all of five seconds to create such a template. [02:25:31] 03(mod) Timestamp in timel should mark its timezone - 10https://bugzilla.wikimedia.org/33454 +comment (10Mark A. Hershberger) [02:25:32] But that's really only for security-related issues. [02:25:37] To which you should just use {{security}} or whatever it is. [02:25:45] * varnent imagines {{CRAP}} containing all of the current extension template to scare all visitors away [02:26:01] 03(mod) Timestamp in timel should mark its timezone - 10https://bugzilla.wikimedia.org/33454 +platformeng (10Mark A. Hershberger) [02:26:27] Wow - is https://www.mediawiki.org/wiki/Extension:Crypto/Version_1.0 really doing encryption by just XOR-ing with some key [02:27:01] In the era where strong crypto is widely available [02:27:25] heck php probably has a function for that builtin [02:29:19] Joan: I was just thinking for the many absolutely shit code extension that you just can't find a glaring security hole in [02:30:01] Well, better to be helpfully critical, though. [02:30:16] {{note|This extension is bad because it does x, y, and z.}} rather than {{crap}}. [02:30:23] Though maing {{crap}} a redirect would be nice. :-) [02:30:24] wooooowww... https://www.mediawiki.org/wiki/Extension:Windows_NTLM_LDAP_Auto_Auth [02:30:42] ....the way it tries to disallow access to normal login functionality [02:30:47] do we have a general security template? I see some variations here - https://www.mediawiki.org/wiki/Project:WikiProject_Extensions/Templates [02:31:24] 03(mod) Special Pages in MiserMode should report Manual:$wgQueryCacheLimit - 10https://bugzilla.wikimedia.org/33456 normal->15enhancement; +need-review +patch; +comment (10Mark A. Hershberger) [02:31:45] lol... <> [02:33:41] 03(mod) Password recovery for Assamese wikipedia mailing list - 10https://bugzilla.wikimedia.org/33457 (10Mark A. Hershberger) [02:34:48] * Dantman wishes preilly were here so he could point out how to fix WURFL [02:35:02] 03(mod) Password recovery for Assamese wikipedia mailing list - 10https://bugzilla.wikimedia.org/33457 +comment (10Mark A. Hershberger) [02:36:12] 03(mod) Error when assigning global group permissions to an account with spaces - 10https://bugzilla.wikimedia.org/33458 (10Mark A. Hershberger) [02:41:43] thedj: did you test the SUBST_ENTITIES thing in https://bugzilla.wikimedia.org/show_bug.cgi?id=31719 ? [02:51:28] 03(mod) Useless "select font" menu on from WebFonts extension when no alternatives are offered - 10https://bugzilla.wikimedia.org/33460 +i18n; summary; +comment (10Mark A. Hershberger) [02:51:59] 03(mod) Translation edits show up on recent changes even if user has bot right - 10https://bugzilla.wikimedia.org/33461 (10Mark A. Hershberger) [02:52:16] 03(mod) Allow and display both wiki name and shell name in dialogs - 10https://bugzilla.wikimedia.org/33462 (10Mark A. Hershberger) [02:52:36] never mind, I tested it [03:09:16] Fun... I finally waded my way through WURFL documentation and trial and error... and finally made it work [03:11:04] TimStarling: Do you happen to know where the X-Device header is set? I'm quite sure it's somewhere in squid/varnish config WMF has for the mobile site [03:12:25] Dantman: varnent https://www.mediawiki.org/wiki/Extension:MoodleGlossary [03:12:34] I don't know much about the mobile site [03:12:45] this is a response header? [03:12:52] TimStarling: No request [03:13:24] johnduhart_: I think that looks good [03:14:16] is there a page on MW.org that lists the "supported" releases - I think there's one on enWP - maybe link to that [03:14:20] TimStarling: From the looks of it WURFL is used in either squid or varnish or something... and used to set an X-Device header which is used to determine if the req should be mobile [03:14:59] Since WURFL is already 'also' being loaded in php I want to make it so that sites without a front end cache can simply work with the built in php [03:15:57] 03tstarling * 10/trunk/phase3/ (RELEASE-NOTES-1.19 includes/media/SVGMetadataExtractor.php): (bug 31719) Revert r107359 and apply a proper solution for entity expansion in SVGs. [03:17:06] 03(FIXED) SVG metadata reader has troubles when the xmlns is set to an entity reference - 10https://bugzilla.wikimedia.org/31719 +comment (10Tim Starling) [03:21:25] Dantman: it's in puppet [03:23:25] https://gerrit.wikimedia.org/r/gitweb?p=operations/puppet.git;a=blob;f=templates/varnish/mobile-frontend.inc.vcl.erb;h=f5f73261f1187ff073f8f0dcdb582a6056fdc2b6;hb=HEAD [03:24:20] Oh... pft [03:25:47] And there's the ?useformat=mobile crap that should be in php [03:26:42] This is a complete mess... [03:28:05] TimStarling: Did you know that MobileFrontend is loading an entire WURFL library. Setting up the config, initializing it, letting it try to dump persistant storage into a local memcached (which is hardcoded into the config and likely broken in most places), and then doing absolutely nothing with the data. [03:28:24] sounds clever [03:28:39] * Joan smiles. [03:33:10] everyone seems to want r103817 but nobody actually wants to do it [03:33:21] to revert it, that is [03:34:01] ...that's cause we're using svn [03:34:21] right, because git doesn't have conflicts [03:34:42] Oh I wasn't thinking about conflicts... [03:35:01] what is the point of ContextSource? [03:35:17] I just would rather dig up the docs for how to revert a git commit than that svn merge command that was needed to revert a svn commit [03:35:49] svn merge -c -103817 . [03:36:29] TimStarling: Poor man's traits I suppose... Making it so we can sanely use getOutput getTitle etc... everywhere instead of seeing getContext->getOutput() ALL OVER code. [03:36:43] yeah but PHP doesn't have multiple inheritance [03:36:52] mhmm [03:36:55] so you can't have traits [03:37:02] ...well, not in pre 5.4 [03:37:13] unless you're happy with only having one trait for anything [03:37:34] anyway you can call getTitle() on something that's not a ContextSource [03:37:50] what is the advantage of having that in a base class? [03:37:55] I guess it's really for those many cases where we actually 'can' simply extend ContextSource [03:38:10] There are a few of them the actual boilerplate needs to be added to. [03:38:41] so the point of it is abbreviation? [03:38:44] But say 9 out of 10 classes we have where a context source makes sense they have no parent class [03:38:56] $this->getLanguage() instead of $this->getContext()->getLanguage()? [03:39:32] mhmm [03:40:06] Don't underestimate the number of places request context stuff needs to be called though [03:41:51] I suppose overrides are also easier [03:42:41] Instead of saying we have a local title, please don't call getContext()->getTitle() make sure you ALWAYS just call getTitle(), or else things will get messed up... you just add your own getTitle and use yourself as the context source when you pass a context somewhere else [03:43:55] 03johnduhart * 10/trunk/extensions/ArticleFeedbackv5/ (ArticleFeedbackv5.i18n.php ArticleFeedbackv5.php): Protocol relative!!!! [03:44:06] as opposed to making a DerivativeContext? [03:45:37] I'm not convinced [03:45:55] I was almost buying it as an abbreviation, but now I'm not convinced again [03:47:09] ...well it's really the abbreviation [03:47:13] ...I just came up with that [03:47:31] Also, DerivitiveContext is based on the IContextSource that ContextSource comes from [03:47:31] DerivativeContext looks like a PITA with 6 member variables [03:48:08] hmmm? [03:48:16] why not just clone the RequestContext? [03:49:01] The possibility that the original request context can change... [03:49:41] and when it changes you want the change to appear in the derivative? [03:50:04] ...that's the general premise of DerivitiveContext [03:50:11] and is that the desired behaviour in some application? [03:50:19] Used when everything is the way you want, except one thing. [03:50:31] because sometimes it makes more sense to have a snapshot of the current state [03:51:06] eg: The request, user, etc... is all right, you want it to be part of the main session. But you want the context to have a different title without actually modifying the main title. [03:52:14] I used it on say Special:History/Foo to give HistoryPage a context where the title is Foo [03:52:27] 03(mod) [SF] Special:RunQuery error takes down pages using it - 10https://bugzilla.wikimedia.org/33424 +comment (10fastgoldfish) [03:52:39] You don't wan't the entire special page to break because suddenly the main title has changed. [03:53:12] sure, but does something actually call any of the RequestContext::set*() functions between when Special:History starts up and when it finishes? [03:53:23] johnduhart_: "+ * @author John Du Hart" made me heh. [03:53:40] heh [03:53:59] TimStarling: Presumably no...... but I don't like edge cases that don't need to be there. [03:54:08] it's an edge case either way [03:55:20] if HistoryPage calls some hook which calls RequestContext::getMain()->setUser(), that's pretty shaky ground no matter which way it is handled [03:55:42] because you don't know what kind of state may have been copied into local variables etc. in HistoryPage already [03:55:54] you don't know the order of checks [03:56:14] which accesses were done on the user object before the hook, which were done after [03:56:28] there's no good solution [03:56:47] apart from not doing such a crazy thing from a hook, use a proper interface instead involving the parameters [03:58:25] Dantman: If I wanted a link added to the Wikipedia footer, would that be a Bugzilla thing? [03:58:34] I guess [03:58:38] Or do we still encourage people to hack it into a MediaWiki message? [03:59:00] the reason I said that 6 member variables looks like a PITA is that some day you might want 7 [03:59:08] 03johnduhart * 10/trunk/extensions/ClickTracking/modules/jquery.clickTracking.js: [03:59:08] Add formats for API calls. [03:59:08] It doesn't matter, it just looks like a legitimate request in firebug or whatever. Plus, I'm sure it takes more time to prettyprint it anyhow. [04:00:17] then you would have to add new methods and variables everywhere, right? [04:00:22] Sure [04:01:46] what does getLanguage() even do? [04:01:56] we have at least 2 language objects [04:02:03] getLang/getLanguage gives you the user Language object [04:02:14] It's $wgLang [04:02:41] strange that that's not documented [04:02:43] Content language didn't exactly belong in the request [04:02:48] It isn't? [04:03:12] Guess the code comments could use a tweak [04:03:33] it's not in any of the doc comments, you have to look at the source of RequestContext [04:03:55] 03(NEW) Add "Developer" or "API" link to footer of Wikimedia wikis - 10https://bugzilla.wikimedia.org/33464 normal; Wikimedia: General/Unknown; (b) [04:07:26] what do you think belongs in RequestContext as opposed to WebRequest? [04:07:50] it seems like there's a bit of redundancy there [04:07:59] WebRequest is more like Database [04:08:23] It's a high level mostly abstract accessor for something. [04:08:37] RequestContext would be actual MediaWiki related stuff [04:09:37] we've been thinking about doing a session project [04:09:51] $_SESSION sucks in a lot of ways so it would be nice to get rid of it [04:09:59] Mhmm [04:10:04] that would imply some sort of session manager object [04:10:13] If it's basic replacement of session data handling it would be WebRequest [04:10:23] Just like cookie, query, post, etc... [04:10:36] well, we have getSessionData()/setSessionData() [04:10:49] but what if you wanted 6 or 8 public methods? [04:11:03] transaction support, persistence, ID switching [04:11:12] But if it gets into actual coded MediaWiki functionality where you interact with it using MediaWiki terms rather than general session terms then it might belong in RequestContext [04:11:35] then it would be outside WebRequest's scope, right? [04:11:36] Sure, when I mean 'belongs in' I mean what you would use to get access to the session manager instance [04:12:03] well yeah, would it be $context->getRequest()->getSession() or $context->getSession() [04:12:14] The stuff you listed sounds fairly abstract [04:12:59] If the session manager had something like setUser then it would be out of WebRequest scope [04:13:29] a session is not really part of a request in the same way that cookies are [04:13:37] cookies come in in headers, they go out in headers [04:13:54] it's an HTTP kind of thing which is WebRequest's traditional area [04:14:20] But if you're talking somewhat abstract functionality on how to handle those transations, persistance, etc... then I'd think it's within WebRequest scope and the rest of MW would use it to interact with the session. [04:14:31] a session on the other hand is server-side data storage keyed by some ID that comes from the request [04:14:42] Sure it's a little funky. [04:14:45] Naming wise. [04:15:11] I think we've been misled by fact that it is a superglobal [04:15:22] and the interface is built in and looks (at first glance) to be fairly simple [04:15:55] Well, we've got WebRequest and RequestContext on the table [04:16:20] Both of them essentially represent something in the current request being processed [04:17:06] The real difference between them being the MediaWiki level and the data interaction (or whatever better term you can come up with) level [04:17:12] ok [04:17:35] the term "request" was pretty muddy to start with [04:18:02] you receive a request, you generate a response [04:18:06] We're talking about data that persists across requests now. [04:18:32] but we don't treat request and response as symmetrical, we have WebRequest::response() [04:18:43] we roll in the processing stage into the request [04:19:00] you know the traditional data processing model: input, processing, output [04:19:04] But even though it persists across requests, the data that says what persistant session the request is part of is still part of the request [04:19:24] yeah sure [04:19:30] the user ID is in the request too [04:19:42] but you wouldn't call all user data "part of the request" [04:19:59] So something like WebRequest::getSession that gets the session manager for the session data relevant to the request seams to make sense [04:21:18] ok [04:23:05] say if we did think of something that needed to be added to RequestContext [04:23:13] TimStarling: ;) Btw, if you want to test how much hassle adding something to our RequestContext stuff is, I've been feeling like adding a getWikiPage to RequestContext [04:23:29]