Wikitech-l May 2011

wikitech-l@lists.wikimedia.org

119 participants
99 discussions

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 09 May '11

09 May '11

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

1 0

AJAX call avoiding CSS error
by Tod 09 May '11

09 May '11

I'd like to make a call to a service on another server and present the results in a mediawiki page. Does the current release of MW (1.16.5 I think) have a built in proxy to support this ? Thanks - Tod

3 3

WYSIWYG and parser plans (was What is wrong with Wikia's WYSIWYG?)
by Brion Vibber 09 May '11

09 May '11

On Mon, May 2, 2011 at 12:04 AM, Tim Starling <tstarling(a)wikimedia.org>wrote: > Can someone please tell me, in precise technical terms, what is wrong > with Wikia's WYSIWYG editor and why we can't use it? > > I have heard that it has bugs in it, but I have not been told exactly > what these bugs are, why they are more relevant for Wikimedia than for > Wikia, or why they can't be fixed. > > Years ago, we talked dismissively about WYSIWYG. We discussed the > features that a WYSIWYG editor would have to have, pointing out how > difficult they would be to implement and how we didn't have the > manpower to pull off such a thing. Now that Wikia has gone ahead and > implemented those exact features, what is the problem? > The most fundamental problem with Wikia's editor remains its fallback behavior when some structure is unsupported: "Source mode required Rich text editing has been disabled because the page contains complex code." Here's an example of unsupported code, the presence of which makes a page permanently uneditable by the rich editor until it's removed: <table> <tr><td>a</td></tr> </table> You can try this out now at http://communitytest.wikia.com/ It will at least let you edit other *sections* that don't contain anything that scares it, but if the nasty bit is somewhere in what you want to edit, it just doesn't recover. There are some smart things in what they're doing: annotating the markup ought to be a big help in hooking up the rendered HTML bits back to the original source. The way they hold template invocations and plugins as standalone placeholders within the rich text is pretty good (and could be a bit better if it could display some content and provide even more advanced invocation editing tools, which is all detail work). But if it just gives up on entire pages, we've got a problem because to handle Wikipedia we need to handle lllooonnnggg pages that tend to include lots of complex templates which pull in funky code of their own. At a minimum, assuming that other round-tripping problems are all resolved and the treatment of templates and extensions can be improved, it would need to be changed to recognize uneditable chunks and present them as a sort of placeholders too -- like the templates you should be able to dive into source and edit them if need be, but they ought not destroy the rest of the page. Beyond that let's flip the question the other way -- what do we *want* out of WYSIWYG editing, and can that tool provide it or what else do we need? I've written up some notes a few weeks ago, which need some more collation & updating from the preliminary experiments I'm doing, and I would strongly appreciate more feedback from you Tim and from everyone else who's been poking about in parser & editing land: http://www.mediawiki.org/wiki/Wikitext.next And also some of Trevor's notes which I have poked at: http://www.mediawiki.org/wiki/Visual_Editor_design I've got some aggressive ideas about normalizing how we deal with template expansion to work at the parse tree level; this can be friendlier to some levels of caching, splitting portions of parsing between PHP and optimized native code, or even mixing some things between pre-parsed text and client-side work, but most importantly I'm interested in making sure we have a relatively clean hierarchical relationship between parts of the document, which we can use to much more reliably hook up parts of the rendered HTML output: * maintain an abstract parse tree that can be hooked up fully to both the original source text *and* the live output DOM * do section, paragraph, or table-cell editing inline directly on a view page, with predictable replacements It may well be that this is too expansive and we'll want to contract to something that's more like Wikia's annotated parser output -- in most cases it should give us similar information but it'll probably be harder to replace parts of the page at runtime in JavaScript. Another goal beyond editing itself is normalizing the world of 'alternate parsers'. There've been several announced recently, and we've got such a large array now of them available, all a little different. We even use mwlib ourselves in the PDF/ODF export deployment, and while we don't maintain that engine we need to coordinate a little with the people who do so that new extensions and structures get handled. A new visual editor that's built around a normalized, defined parser could be a great help; other folks will be able to use compatible parsers instead of mostly-similar parsers. For the moment I'm mostly schooling myself on the current state of the world and setting up experimental tools to aid in debugging extra parser/editor-related goodies (eg the inspector tool I'm fiddling with at http://en.wikipedia.org/wiki/User:Brion_VIBBER/vector.js ), but hope to get some of these projects starting moving forward after Berlin. -- brion

32 96

Bugzilla Weekly Report
by reporter 08 May '11

08 May '11

MediaWiki Bugzilla Report for May 02, 2011 - May 09, 2011 Status changes this week Bugs NEW : 249 Bugs ASSIGNED : 19 Bugs REOPENED : 28 Bugs RESOLVED : 145 Total bugs still open: 5821 Resolutions for the week: Bugs marked FIXED : 92 Bugs marked REMIND : 0 Bugs marked INVALID : 11 Bugs marked DUPLICATE : 24 Bugs marked WONTFIX : 13 Bugs marked WORKSFORME : 5 Bugs marked LATER : 2 Bugs marked MOVED : 0 Specific Product/Component Resolutions & User Metrics New Bugs Per Component General/Unknown 6 Site requests 4 Special pages 3 History/Diffs 3 Images and files 3 New Bugs Per Product MediaWiki 38 Wikimedia 12 MediaWiki extensions 20 Wikipedia Mobile 3 Security 1 Top 5 Bug Resolvers krinklemail [AT] gmail.com 18 diebuche [AT] gmail.com 12 innocentkiller [AT] gmail.com 10 mah [AT] everybody.org 8 pdhanda [AT] wikimedia.org 5

1 0

RFC: Change of RELEASE-NOTES location for trunk
by Platonides 07 May '11

07 May '11

MediaWiki is currently developed in two branches, with everything going to trunk, and a slower number of revisions getting also copied to the stable branch. That's also the way we want to continue working, having a trunk and a stable branch. Currently we store the release notes in a file called RELEASE-NOTES in the phase3 root of each branch. This is a problem when adding a revision for backport, since the release notes are not suitable to be added to the trunk RELEASE-NOTES (they would go inside HISTORY) but it needs to be added to REL1_X RELEASE-NOTES. So we end up with release notes added in a different commit, or revisions with merge conflicts for merging. Which is inconvenient. Thus, I propose that, from the point we branch 1.18, we keep the stable branch release notes in trunk, and add trunk release notes in a different file. trunk and branch RELEASE-NOTES would effectively be the same file (a revision modifing RELEASE-NOTES and not tagged for backport would be a bug). This simple change would give us much cleaner merges. When tagging a new branch, the trunk RELEASE-NOTES would move to HISTORY, the trunk release notes file to RELEASE-NOTES and a new one would be created for trunk.

2 3

Merging WikiEditor into core
by Andrew Garrett 06 May '11

06 May '11

Hi all, Do we have plans to merge WikiEditor into core, and make it the default (and only) editing toolbar? If not, I'd like to propose that we do so at some point (perhaps for 1.18?). It's infinitely better than the old one, very useful, extensible and really ought to be the only way forward for MediaWiki. What do other people think? —Andrew -- Andrew Garrett Wikimedia Foundation agarrett(a)wikimedia.org

8 8

1.18 branched and code review
by mhershberger＠wikimedia.org 06 May '11

06 May '11

This morning I talked to Roan about his thoughts about branching 1.18 now that 1.17beta1 is out. He was in favor of it so I said I would ask Tim what he thought and then (assuming Tim was OK with it) branch it. So, after asking Tim for his POV and getting his OK, I went ahead and created http://svn.wikimedia.org/mediawiki/branches/REL1_18/ to hold phase3. I recognize that I will have to be prepared to merge fixes that fix bugs in 1.17 with the branch I've just created — but I'm anxious to get the 1.18 release on the road NOW. Along with this, I'm going to be coordinating code review with the developers and making sure we're aware of our respective areas of responsibility. I think we're agreed that the keeping CR current is necessary to have a timely 1.18 release and avoid delays. Happy hacking! Mark.

2 1

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

2025

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