Wikitech-l May 2011

wikitech-l@lists.wikimedia.org

119 participants
95 discussions

DOM, onload, and custom javascript
by Tod 11 May '11

11 May '11

I've modified Mediawiki:Common.js to include the following: document.getElementById("p1").innerHTML="New text!"; I then created a page called testPage and inserted: <p id="p1">Hello World!</p> I'm expecting the text to change upon load but nothing is happening. Prior to the <p> tag addition I had an alert that was working as expected so at least I know Common.js is working. What is the best practice for adding custom javascript code in Mediawiki? While we're at it is there a real good tutorial on including AJAX calls w/o needing an extension anywhere? Thanks - Tod

5 16

Spay or neuter your jQuery libraries before they multiply!
by Brion Vibber 11 May '11

11 May '11

If folks are looking for an easy introduction to working with ResourceLoader, one way might be to help with bug 26306 "Cleanup extensions that include jquery (and common plugins) themselves": https://bugzilla.wikimedia.org/show_bug.cgi?id=26306 A number of extensions over the years have pulled in their own copies of jQuery, or particular jQuery or jQuery.ui plugins which are now present in MediaWiki core and available through ResourceLoader. The extra copies -- which are usually horribly out of date! -- can generally now be removed. Here are commits I made on a couple extensions: OpenID: needed conversion to RL, used the opportunity to clean up other minification/spriting http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87845 Collection: most of the old modules had already been switched to RL but the old files were still there. Cleaned up and swapped one more plugin for the core copy http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87847 Don't be afraid to check out http://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_for_extension_… related doc pages on mediawiki.org, or bug your fellows -- anything that's not clear now is something that should be documented better, so don't be shy! -- brion

5 5

Large number of users unable to access WMF wikis
by John 11 May '11

11 May '11

For about the last 12 hours I have been unable to reliably connect to WMF wikis. Ive tried both Firefox and IE8 both without success. Pages either load and proceed to hang forever, or partial page contents are loaded. There have been multiple reports in -tech about this from multiple people spanning at least half the globe. traceroute: 15 77 ms 56 ms 112 ms te1-2-0d0.cir1.chicago2-il.us.xo.net[216.156.72.5] 16 55 ms 57 ms 60 ms 207.88.14.201.ptr.us.xo.net [207.88.14.201] 17 80 ms 83 ms 84 ms te-3-0-0.rar3.washington-dc.us.xo.net[207.88.12.74] 18 86 ms 104 ms 99 ms te-3-0-0.rar3.atlanta-ga.us.xo.net[207.88.12.9] 19 103 ms 116 ms 87 ms te-4-0-0.rar3.miami-fl.us.xo.net[207.88.12.6] 20 85 ms 122 ms 91 ms 207.88.14.58.ptr.us.xo.net [207.88.14.58] 21 102 ms 93 ms 91 ms w006.z207088246.xo.cnc.net [207.88.246.6] 22 191 ms 207 ms * text.pmtpa.wikimedia.org [208.80.152.2] 23 * * 219 ms text.pmtpa.wikimedia.org [208.80.152.2] and ping results Pinging text.pmtpa.wikimedia.org [208.80.152.2] with 32 bytes of data: Request timed out. Request timed out. Request timed out. Reply from 208.80.152.2: bytes=32 time=164ms TTL=45 Ping statistics for 208.80.152.2: Packets: Sent = 4, Received = 1, Lost = 3 (75% loss), Approximate round trip times in milli-seconds: Minimum = 164ms, Maximum = 164ms, Average = 164ms Hope this helps someone figure out the problem John

5 5

MediaWiki Supported Browser List
by Trevor Parscal 11 May '11

11 May '11

After the question came up a few times, Ryan Kaldari and I decided to document the official list of supported browsers and the information and logic that surrounds this topic. http://www.mediawiki.org/wiki/Supported_browsers - Trevor

11 16

Bugzilla API and stats (and CR)
by mhershberger＠wikimedia.org 11 May '11

11 May '11

I've talked a bit on IRC about how I'm using the Bugzilla API to create various reports. Some people have shown interest — IIRC, MZMcBride said I should create a graph or report showing which bugs have how many duplicates. I haven't done that, but I did create an example Bz API client that I adapt and can use for writing reports on, for example, our weekly bug triage. I took advantage of the MWHttpRequest built into MediaWiki, rather than depending on one of the plethora of PHP-based HTTP client code bases (like the one available at http://snoopy.sf.net/) and I modified the JSON RPC client at http://jsonrpcphp.org/ to use the MWHttpRequest class. This means you'll have to set $IP and set the MEDIAWIKI constant to true before including bugzilla.php as I've done in http://svn.wikimedia.org/svnroot/mediawiki/trunk/tools/bugzilla/client/main… The sample code I've committed in main.php is supposed to show all normal or higher priority bugs in bugzilla after their assignee's emails. This sort of report was useful for me this past week when I sent nagging emails to MW developers. Also, after talking to robla today, I went ahead and downloaded a 23mb mbox file from gmane.org (since one wasn't available from wikimedia.org) and I'll be working on charting our most prolific bug closers, as well as other data. Another thing I've been working on is getting more people involved in code review so that our 1.18 won't be delayed becase of the lack of code reviewers. See everyone in Berlin, (everyone who is going to be there, anyway) Mark.

1 0

integration of MediaWiki and version control system as backend?
by Heiko Nardmann 11 May '11

11 May '11

Hello together! Is it possible to have a version control system, e.g. Subversion or Git, as the backend for MediaWiki instead of a DBMS ? So far I did not found anything in this direction ... If not possible: is this due to data model mismatches or "just" missing man power to have it implemented? Thanks in advance! Heiko Nardmann

8 8

Realtime collaborative editing of MediaWiki articles, with Hackpad
by Neil Kandalgaonkar 10 May '11

10 May '11

Last week I collaborated with some local hackers on putting realtime collaborative editing into MediaWiki. That is, where a number of people can be editing the same article at once, and seeing each others' changes in real time. We've been using Etherpad a lot at the WMF so we wanted to see what would happen if this style of editing were brought to wikis. I had some friends of friends who have an Etherpad-derivative startup called Hackpad. We got together and decided to do a sprint for a couple of days on this idea. The resulting interface is good proof of concept! Check out their blog post. http://hackpad.posterous.com/live-editing-mediawiki-with-hackpad We learned a lot, particularly about where the points of agreement and disagreement are between the Etherpad and MediaWiki ways of thinking about editing. FYI: parts of Hackpad are integrated with Facebook. One of Hackpad's innovations was to add authentication to Etherpad, particularly Facebook's auth. You won't have to log in to use this demo but it still pings their servers. This doesn't herald any new turn of Wikimedia towards Facebook. Also, the article may be bunched onto one line and be all in bold -- this is an artifact of Hackpad using the first line of an article as the headline. Hackpad has promised to me they'll be publishing some relevant changes they made to Etherpad for this project, so other Etherpad hackers can do the same thing. I've been talking with Trevor & Brion about doing an extension+gadget to make it easier to invoke a "remote" web-based editor with MediaWiki. The current WikiEditor sort of has an iframe-crossing API already built into it, so that might be a place to start. -- Neil Kandalgaonkar ) <neilk(a)wikimedia.org>

2 1

Bug Triage meeting notes
by mhershberger＠wikimedia.org 10 May '11

10 May '11

The Berlin Hack-a-thon (http://hexm.de/2o) and a variety of CSS-related bugs possibly caused by the recent IE fixes dominated the discussion durin this week's bug triage. Here's the bugs we discussed and a quick summary of the decided course of action. == Bugsmash == * http://bugzilla.wikimedia.org/11415: __EDITPARENTSECTION__ I brought up this old enhancement request since it looks like it has a lot of people chiming in still. It seems a little hairy, but would make a good candidate for our upcoming Berlin Hack-a-thon. (i.e. “bugsmash” tag) * http://bugzilla.wikimedia.org/28819: Deleted revision links should use "rev_id" not "page/timestamp" * http://bugzilla.wikimedia.org/28820: Diffs using rev_id should work when one or both revisions are deleted * http://bugzilla.wikimedia.org/18104: Schema request change so deleted edits are identified by revisionID Brion created thesee bugs which could each be resolved somewhat independently and suggested them for bugsmash in triage * http://bugzilla.wikimedia.org/28829: Failure to subscribe to mediawiki-announce is not reported to the user * http://bugzilla.wikimedia.org/28845: PostgresInstaller::canCreateAccounts() gives the wrong result * http://bugzilla.wikimedia.org/20814: Enable $wgCrossSiteAJAXdomains for wikimedia sites This isn't going to happen with the code as it exists right now. Tim has updated the bug with a comment outlining the problems and I asked him on IRC to create a new bug specifically addressing the problems that need to be addressed in MediaWiki before this can be done. * http://bugzilla.wikimedia.org/28839: Interwiki may circumvent blacklist Someone can do a SMOP that would find abusable interwiki links. == CSS errors == * http://bugzilla.wikimedia.org/28891: Regression? Clicking on non-existing image link does not redirect to upload anymore * http://bugzilla.wikimedia.org/28840: Diffs not displaying correctly in IE because mediawiki thinks the … * http://bugzilla.wikimedia.org/28857: Sometimes there's "undefined" in a Resource loader CSS request Tim said Roan probably has a patch for this particular bug. Need to get it applied (if it hasn't been already) and tested. I've emailed Roan. * http://bugzilla.wikimedia.org/28851: Display problem on ku.wikipedia This is likely be caused one of the other general CSS-breakage or RL-breakage issues. I'll recheck after the other CSS bugs (above) have been fixed. == Other problems == * http://bugzilla.wikimedia.org/28889: out of memory error when deleting messages on commons Fairly isolated since it only happens with a couple of specific messages on the Commons, which does a lot of customization. Lowered the priority but asked for other instances of the problem. * http://bugzilla.wikimedia.org/28827: High NEW PHP Catchable fatal error: Argument 1 passed to RequestContext::setTitle() must be an instance of Title, null given Translatewiki brought this one up because no one had been able to deal with it yet on IRC. We asked translatewiki for traceback and I assigned to dantman since he was working on this code. * http://bugzilla.wikimedia.org/28842: user rights issue with vector and new editor Tim is on top of this one and thinks it is an extension problem. * http://bugzilla.wikimedia.org/28843: Customizable cite error My description wasn't clear enough — asked Happy-Melon to help me clarify it.

2 1

Wikimedia engineering April 2011 report
by Guillaume Paumier 10 May '11

10 May '11

Hi, The (slightly delayed) report of Wikimedia engineering activities for April 2011 is out: http://blog.wikimedia.org/2011/05/10/wikimedia-engineering-april-2011-repor… -- Guillaume Paumier

1 0

New Committer
by Ryan Lane 10 May '11

10 May '11

Added Asher Feldman (asher) to extensions, core, and deployment. He's a new member of the Operations team. - Ryan

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l May 2011