IRC office hours/Office hours 2011-02-14

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search

<guillom> ok
<guillom> so, let's start
<matanya> first?
<guillom> sure
<matanya> thanks
<matanya> as a maintainer of a few scripts on hewbrew wiki
<neilk_> RoanKattouw: he's joining in now, don't call
<guillom> Let's do this quite informally; if you have questions, ask them, and if we get too many of them we'll throttle
<RoanKattouw> OK, I hung up
<guillom> thanks neilk_
<TrevorParscal> hello
<guillom> hi TrevorParscal :)
<matanya> I want to ask if the userscripts will break for sure, and if yes, what should be done to take care of it
<RoanKattouw> User scripts will not "break for sure"
<RoanKattouw> We did a number of things to keep backwards compatibility
<RoanKattouw> But certain delicate things will break
<guillom> (handy links: )
<Krinkle> especially the latter for Wikimedia editors / end-users
<Bryan> can you list things that break for sure? (document.write etc)
<Guandalug> Short question: Will there be a wrapper for 'addOnloadHook()' already loaded by the time gadgets and userscripts run for the moment? I know it's going away and all, but....
<RoanKattouw> Good one
<Krinkle> document.write breaking is not entirely new to 1.17, but it's noted there
<Krinkle> under Good practices
<RoanKattouw> Guandalug: addOnloadHook() is still around. It's not going away in the short term. But of course using $(document).ready(function() { ... } ); is better
<RoanKattouw> So document.write
<Guandalug> RoanKattouw: Thanks. I'll make sure to migrate stuff.... 'soon' ;)
<RoanKattouw> has always been something that's usually a bad idea, it breaks in various cases and works only in some
<brion_> And don't forget -- you can try out your scripts now on or the other wikis that have already migrated
<RoanKattouw> Good point there brion
<RoanKattouw> What we did is change the script loading order a bit, which means the cases in which document.write will work are reduced to (almost?) none
<matanya> what about global scripts in common.js ?
<RoanKattouw> Short version: document.write probably won't work any more, but if it did before that was probably by accident anyway
<RoanKattouw> matanya: What about them?
<Guandalug> *gulp* That might (tm) break one of the most commonly used user script on deWP.... but then, it might not, we'll have to wait and see
<matanya> we took some useful userscript and put them there, may break too?
<guillom> matanya, it doesn't matter if it's a global script or a personal one (except that the global one will affect more people if it's broken)
<TrevorParscal> MediaWiki:Common.js is still loaded
<TrevorParscal> and it's loaded last
<TrevorParscal> and in a way that ensures it doesn't need to mind the details of ResourceLoader
<TrevorParscal> this is to improve backwards compat
<brion_> Guandalug: which script? anything we could do to help test it before rollout on dewp?
<kaldari> if any userscripts or common.js scripts that are widely used use document.write I can probably help rewrite them, just let me know and I'll take a look.
<Krinkle> There's a weird <preview> thing on edit pages of, I dont see that on other 1.17 wikis
<RoanKattouw> Sounds like msg breakage due to 1.17 upgrade I guess
<Guandalug> brion_: Ever heard of PDDs "monobook suite"? It's more than a few files..... and the big thing that everybody has builds a GUI box, and writes it to the stream.
<Krinkle> I thought preview-tab was disabled
<matanya> and if something is broken there, the rest of common.js won't load, right?
<brion_> Guandalug: not familiar with it no, sounds... exciting :D
<RoanKattouw> Krinkle: I guess you're getting hit by the legacy preferences bug. I need to clean that out of the DB tables later
<TrevorParscal> that wouldn't be the preview tab, it would be the preview dialog - in that location
<RoanKattouw> matanya: A JS error in Common.js will stop the rest of Common.js from loading, yes, but that's always been the case
<Krinkle> TrevorParscal: When I save the page (normally) I get a grey overlay and then it dissapears and saves the page.
<matanya> I know, just wanted to know how urgent it is...
<Guandalug> brion_: .... and that one's copied over and adapted by a few hundred users. (Me too, once, but I switched to vector and most of my stuff is jQuery already)
<RoanKattouw> Krinkle: You have a disabled preference enabled somehow. I'll fix this later
<Krinkle> k
<RoanKattouw> I guess this is a regression in 1.17 btw
<TrevorParscal> Krinkle: well, the previewDialog module shouldn't be deployed, it was never stablized
<Krinkle> indeed
<brion_> those document.write's should be changeable pretty easily
<brion_> $('body').append() is pretty equivalent if you build together in a chunk but doesn't suck ;)
<Guandalug> brion_: Sure.... but as I said, it's been copied. And the copy modified. A lot. I guess PPL will start to complain ;)
<brion_> then they'll need to fix em. no worries, that's just regular growing pains
<kaldari> why was it copied instead of shared?
<RoanKattouw> Why did no one make this a gadget then?
<RoanKattouw> What kaldari said
<brion_> (that'd be a good next step)
<brion_> note there's a "monobook suite" on es.wikipedia as well, so there may be more variants of this
<brion_> [reminds me -- cross-site gadget sharing would be rather handy in future]
<kaldari> brion_: yes, please :)
<Guandalug> kaldari: Because back when this thing started to be popular, the gadget-Stuff wasn't as good as it is now.... Plus, the configurability of this beast interferes with a gadget-Setup.
<RoanKattouw> Hmm, the Gadgets extension has been RL-ified too
<RoanKattouw> I wonder how that'll work out, I must admit I don't know how well the author has considered back compat
<Guandalug> That MIGHT be the reason some Gadgets on deWP broke when the last attempt of upgrading to 1.17 were active... but it's not sure it was the gadgets, or a loading problem somewhere else
<Krinkle> brion: Although it takes an http request I encourage users in the migration guide (mw:RL/MGU) to replace gadgets that are stored on with a call to mw.loader.load (or importScriptURI for that matter).
<guillom> RoanKattouw, is the plan still to upgrade all the remaining wikis to 1.17 this Wednesday?
<RoanKattouw> I must admit I don't know
<RoanKattouw> robla: -----^^
<robla> yup
<RoanKattouw> Oh look
<darkcode> I thought backwards compatibility wasn't something to worry about until @import breakage appeared, I had already been upgrading gadgets used at a project to use jQuery
<Guandalug> mw.loader.load ? *notes down* No need for an own importScriptURI - extension for jQuery.
<RoanKattouw> It looks like we're not deploying the RL-ification of Gadgets
<Krinkle> Guandalug: check mw:RL/DM and mw:RL/JD
<brion_> ok so that's one less thing to worry about for now :D
<RoanKattouw> Guandalug: Yeah mw.loader.load() will do almost the same as importScriptURI() except that 1) it requires the URL start with http:// or https:// and 2) it doesn't prevent duplicate loading
<Krinkle> Look for "importscript" script and "loader"
<RoanKattouw> These things will probably be fixed in a later iteration of ResourceLoader
<guillom> So, about this "list of things that will break". Is a comprehensive such list?
<Krinkle> guillom: NO
<Krinkle> It is not a list of things that will break
<Krinkle> it is a list of things that have a newer version in 1.17 but still work 99.9%
<guillom> Krinkle, ok, do we have such a list, then? :)
<Bryan> Krinkle: btw, we might want to test commons' upload form js before wednesday
<Krinkle> guillom:
<Bryan> I should write a script to import all Commons' JS to test2
<guillom> ok
<kaldari> Bryan: good idea
<RoanKattouw> Hmm it looks like we *do* have the RL version of Gadgets, but maybe it doesn't use RL by default unless specifically indicated in the Gadget list. Or something
<TrevorParscal> who ported that?
<RoanKattouw> I'm trying to remember
<RoanKattouw> I'm sure svn blame will help me
<^demon> MaxSem did the post-RL gadget work I believe.
<RoanKattouw> maxsem
<RoanKattouw> Yeah
<darkcode> as long as there aren't any other unforeseen and overlooked glitches, fixing relative urls in @import should address all issues that Wikibooks is likely to have until such time as people decide mw.legacy should go away too
<RoanKattouw> Yeah about @impotr
<RoanKattouw> TrevorParscal: Did you think about a fix for that?
<TrevorParscal> I patched that partially

  • Guandalug read somewhere that to make a Gadget use RL, it has to be renamed somewhat

<RoanKattouw> How? Revid?
<TrevorParscal> what i did is add remapping to CSS that came from wiki pages
<TrevorParscal> unfortunately it doesn't handle all cases well enough yet
<RoanKattouw> Ah yes, here we go. Gadgets must be explicitly flagged as using RL
<darkcode> but it missed a "/" somewhere
<RoanKattouw> So the old ones ought to be fine
<kaldari> Will RL be deployed to prior to the other wikis?
<darkcode> I proposed a few suggestions to reduce a need to handle all possible cases
<RoanKattouw> No, but we have test2
<TrevorParscal> I tested it with "url(this/that)" and "url(http://this/that)" but I guess there are some other cases that need some love
<darkcode> on the bug
<RoanKattouw> Yeah see CR
<RoanKattouw> Also, it needs 1.17wmf1 and 1.17 tagging
<TrevorParscal> So, i am on that - but it's not 100% done just yet
<Krinkle> background http:// problems
<TrevorParscal> For that matter - this is my hit list
<TrevorParscal> any help on that stuff would be great of course :)
<darkcode> url("Page.css") is my favorite, but it doesn't handle page names that look like urls, so I suggested url("mw://Page.css") too
<kaldari> Is RL currently deployed to anything besides test2? Sorry if this has already been covered.
<Krinkle> kaldari: Yes
<RoanKattouw> kaldari:
<kaldari> thanks!
<TrevorParscal> Krinkle: can we get that bug (27396) to show up on that dep tree list?
<RoanKattouw> darkcode: Feature requests are always welcome in Bugzilla, but right now we're focusing on bugs of course
<RoanKattouw> TrevorParscal: Mark it as Blocks 26611
<Krinkle> TrevorParscal: I haven't reproduced it on trunk yet.
<Krinkle> I mean 1.17 *
<darkcode> RoanKattousw that is related to a bug thats been reported
<RoanKattouw> darkcode: Then add a comment there. As long as your suggestion doesn't get lost :)
<darkcode> it was
<RoanKattouw> I like it, but I will forget for sure
<RoanKattouw> OK
<darkcode> it was suggested there, I just thought I would repeat it here
<RoanKattouw> Right
<RoanKattouw> Alright, so does anyone have any more questions?
<guillom> So, do we have any other questions?
<guillom> heh
<guillom> Take advantage of it while our developers are around :)
<guillom> And while you can fix your JavaScript before the deployment
<kaldari> it looks like 1.17 might breaks the common Main Page tab rename hack in many wikis Common.js...
<kaldari> I'll see about getting these fixed beforehand
<Krinkle> kaldari: Already done
<Krinkle> kaldari: Due to <a> -> <a>
<Krinkle> Advantage: Now that <a> is the inner most one, the same script can be used for vector and Monobook.
<RoanKattouw> Ah right
<kaldari> Krinkle: ah good, we'll still need to go through all the wikis and actually implement the fix though
<darkcode> will a fix for @import urls be making the mediawiki 1.17 cut? so I know if temporary work arounds should be used which I'm sure not all will be happy with but will likely accept knowing its just temporary
<Krinkle> kaldari:
<TrevorParscal> darkcode: it's a blocking bug, so yes it will
<darkcode> ok
<Krinkle> I'm currently using the dozen wikis that have already been switched to try and find as much common js/css things as possible and document them on jQuery_snippets or Migration_guide
<guillom> Krinkle, done
<Krinkle> guillom: Thx
<guillom> np
<guillom> Krinkle, if other people need it to help, feel free to send them to me
<kaldari> Krinkle: awesome, any plan to recruit people to help with the Tour de Wiki. Sounds like a big project.
<darkcode> Kirnkle try looking at some of English Wikibooks stuff in MediaWiki namespace, plenty of jQuery there
<kaldari> might be worth some blog promotion on tech blog or somewhere
<matanya> Krinkle : me too
<Krinkle> kaldari: yes, experience is important (the bar is fairly high to join the tour)
<kaldari> I'd like to help, feel free to msg me once it gets underway
<Krinkle> kaldari: I've already started on simple.wikipedia. Read the Tour-page Checklist and quickly go through my contributions.
<Krinkle> Be sure to update the table when you start on a wiki.
<kaldari> will do, thanks
<Krinkle> contribs on simplewiki* that is.
<kaldari> got it
<darkcode> what if any strategies are planned to alert script writers and encourage them to upgrade their scripts across all the wikimedia projects?
<RoanKattouw> Well, Guillaume posted to wikitech-l last week encouraging those people to come here
<guillom> darkcode, well, that was sort of the point of this IRC office hour, and the associated announcements
<guillom> But as I suspected, I think many people don't care much until things are broken :)
<darkcode> well look at English Wikibooks as an example, seems some people are not exactly script writers, they just copied over entire scripts in some cases instead of using importScriptURI
<rottt> Then they'll all come crawling back. ;)
<guillom> Maybe we'll have to do another session once 1.17 is deployed
<darkcode> and not everyone is subscribed to mailing lists
<Guandalug> guillom: Better wear a flameproof suit then :D
<guillom> darkcode, are you saying we need a better communication system that doesn't involve mailing lists or CentralNotice? Yes, we do :)
<darkcode> I'm saying need a better strategy, not sure communication is enough
<guillom> Maybe I'll do another round of CentralNotice for small wikis
<guillom> darkcode, well, I'm all ears :)
<kaldari> we could run a CentralNotice banner just to logged in users or just to admins warning of the upgrade and potential issues (if we aren't planning on doing that already)
<guillom> kaldari, we are (planning)
<Theo10011> just the admins?
<guillom> for logged-in users
<Theo10011> can central notice target user flags
<Theo10011> I thought so
<guillom> well, kaldari would know
<guillom> I wouldn't
<guillom> :)
<darkcode> I figured English Wikipedia is likely to come up with a plan first once enough things break, though it would be nice to fix things before they break
<kaldari> Theo10011: no, but you can fake it with a couple lines of jQuery.
<guillom> I'd think the English Wikipedia is the most likely to fix things before they break
<rottt> Hm. Search autocompletion doesn't seem to be working on the non-Vector skins.
<rottt> Not gadget-related though, so feel free to ignore me. :)
<guillom> kaldari, by the way, any chance we'll have a per-wiki selection (à la SiteMatrix) in CentralNotice one day?
<darkcode> guillom I already began to fix things at English Wikibooks when 1.16 was deployed, but not in user space, not sure what the best strategy is there
<RoanKattouw> rottt: Yes :(
<RoanKattouw> I need to work on that
<kaldari> guillom: if you can come up with a good interface for it :)
<guillom> darkcode, ah, I see what you mean now.
<Theo10011_> wouldn't it be simpler to just post on ANI and VP?
<matanya> (and not on IE6 too)
<guillom> So, I guess the next step will be to include links to the RL migration guides in the next landing page for Global maintenance notice.
<guillom> anything else?
<guillom> So, I guess we'll thank Roan and Trevor for being available.
<Guandalug> Many thanks for the Info and the links. It has given us much to work on... but much to work WITH as well.
<helderwiki> One more question: Is it good idea to change wg* variables to mw.config.get( 'wg*' ) when 1.17 is live?
<Theo10011> Roan and trevor would be in the tech channel for the deployment, right?
<TrevorParscal> helderwiki: yes
<guillom> Theo10011, it depends on what time it is; at least one of them should be around
<TrevorParscal> we will eventually stop poluting the window object
<Theo10011> k.
<TrevorParscal> we don't know when we will make that switch, but it's going to happen at some point
<RoanKattouw> Theo10011: I hang out in #mediawiki, #wikimedia-tech and #wikimedia-dev when I'm around, and I will be around whenever there's a deployment going on
<helderwiki> TrevorParscal: thanks
<RoanKattouw> Trevor will probably be asleep for most of the deployment on Wednesday
<TrevorParscal> I'm in #wikimedia-dev and #wikimedia
<Theo10011> Thanks Roan.
<darkcode> guillom: was my attempt to compile a list of pages to keep a watch out for
<guillom> darkcode, I also assume lots of people wouldn't know how to fix the JS they copied from somewhere else, so as long as there are people on their wiki who know what's coming, and how to fix it, we also have to trust local communities and their ability to fix these issues themselves.
<darkcode> exactly, lots of people won't know how to fix JS they copied somewhere else. I probably need to start local discussion on this to see how the community wants to handle it
<helderwiki> TrevorParscal: On mw:ResourceLoader there is something about "batch loading resources (which reduces the number of requests made)". Is this something that is also available to user scripts? Is there any docs on this?
<Krinkle> darkcode: For that reason it is important that javascript is kept where it came from. If someone copies it from somewhere, the creator of it can't update it.
<Krinkle> So intead of copying, mw.loader.load
<RoanKattouw> helderwiki: No, not for user scripts. Maybe in the future. It's available for Gadgets if they mark themselves as RL-compatible
<Krinkle> Example:
<TrevorParscal> yes, what he said
<darkcode> Krinkle I agree, but the average person doesn't understand this
<TrevorParscal> short answer... "coming soon"
<helderwiki> E.g.: Then would it be possible to have lots of User:UserName/...js pages loaded in one only request?
<Krinkle> darkcode: Which is why this one-time sweep is done to make sure everything is linked centrally, that way when the next update comes developers can update it themselfs and only once.
<Krinkle> helderwiki: No, not now.
<darkcode> Krinkle though occasionally people have good reasons to copy in order to fork but than they should know what to do
<Krinkle> darkcode: I have yet to come accross that (assuming we're talking about gadgets and not small snippets)
<helderwiki> Krinkle: I think I understood, but is it this kind of thing that RL does? (for core/extensions scripts)
<Krinkle> Yes
<darkcode> Krinkle, I guess Wikibooks may be more likely to fork than other projects, needing things to work on a book level than an article level
<helderwiki> Just to be sure: this grouping of scripts is not available for common.js scripts either (at the moment), right? Are there bug requests for any of these?
<Krinkle> darkcode: Maybe, maybe not. But in most cases the problem is in the gadget if it assumes anything like that. It is possible to make the gadget in such a way so that it'll function fine for both.
<helderwiki> RoanKattouw: How to "mark [the gadgets] themselves as RL-compatible"?
<RoanKattouw> I don't really know
<darkcode> Krinkle sure it depends on what a gadget does, or a community wanting things done differently
<RoanKattouw> I didn't write that, I just figured some things out from reading the code during the office hour
<helderwiki> RoanKattouw: I see.. Is there any gadget marked as RL compatible?
<RoanKattouw> Not that I know of
<TrevorParscal> me either
<RoanKattouw> That'd be a local community thing, anyway
<TrevorParscal> that port happened outside of our work really
<RoanKattouw> You know how there's like MediaWiki:Gadget-list or whatever it's called?
<RoanKattouw> That's where you can mark Gadgets for RL and add parameters like dependencies and such
<RoanKattouw> I'm not sure there's documentation other than the code itself
<Krinkle> Gadget-definition
<Krinkle> MediaWiki:Gadgets-definition
<helderwiki> Thank you all :-)