Wikitech-l May 2011

wikitech-l@lists.wikimedia.org

119 participants
95 discussions

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

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

07 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

mwdumper development
by Johannes Weberhofer 06 May '11

06 May '11

Dear developers, last year I have posted a huge patch on https://bugzilla.wikimedia.org/show_bug.cgi?id=23506 , which * makes code Java 1.5+ compatible * changes to the Java 1.5 AWT layout (no other libraries are necessary) * Switch over to full maven build * Creates different flavours of packages (library, source, runnable jar) * Refactored the directory structure ( /src -> /src/main ) * Includes the commons-compress libraries from apache As I'd like to improve + package it I would like to know, if there is anyone working on that. I don't have too much time, I'd like to prevent double-work and I'd like to know if there is any interest to include those changes. Best regards, Johannes Weberhofer -- Johannes Weberhofer Weberhofer GmbH, Austria, Vienna

1 0

Please welcome Asher Feldman
by CT Woo 06 May '11

06 May '11

Hi Everyone, Please join me in welcoming Asher Feldman to the Wikimedia Foundation where he is our newest member of the Technical Operations team. He will be starting in the San Francisco office on May 9, 2011, but you may see him around before then. He uses the nick handle of binasher in IRC. Asher comes with a broad set of database and systems expertise and as a Performance Engineer here, his focus will be on end-to-end stack tuning and troubleshooting, to drive better web site performance, availability, scalability and efficiency. In his previous jobs, Asher has worked on building and supporting high traffic web properties (e.g., Amazon and Flickr) and non-profits as well (Kiva.org, where he overhauled their web infrastructure and still assists in an advisory capacity.) In addition, he has held senior systems roles in EDS, Barclays Global Investors and Ofoto (Kodak.) Besides being a self professed 'geek', Asher is a fan of live and dj'd music, epicurean of fine and local foods, caudata wrangler, knitter, and a whiskey taster. He is the proud father of Hazel, who is an ardent fan of Roald Dahl, loves growing and collecting crystals, and all things related to the brothers Mario. Do drop by 3rd Floor to say hi to him. Thanks, CT

1 0

getFullPath() deprecated
by Russell N. Nelson - rnnelson 06 May '11

06 May '11

With encouragement from folks on#mediawiki, I'm being bold and proposing that we deprecate getFullPath(). All it does is call getPath(), and there are only three in-tree consumers of it, as opposed to a bazillion consumers of getPath(): http://toolserver.org/~krinkle/wikimedia-svn-search/view.php?id=193&hash=d9…

2 1

Berlin hackathon next week -- bugs to smash?
by Sumana Harihareswara 05 May '11

05 May '11

Looking forward to seeing those of you who can make it to the Berlin Hackathon 2011, 13-15 May: http://www.mediawiki.org/wiki/Berlin_Hackathon_2011 One activity people love at these hackfests: fixing lots of bugs together. Mark and I have marked about 40 bugs for Berlin, concentrating on well-defined small standalone bugs with good steps-to-reproduce. If you know of another bug with those characteristics, feel free to tag it. https://bugzilla.wikimedia.org/buglist.cgi?keywords=bugsmash&list_id=5492 We're planning on hacking throughout -- if you have an idea for a project you want people to sprint on, show up & tell people! We will allow for really tiny presentations, preferably ones that end with either decisions or "and therefore now we shall hack on foo." :-) Thanks so much to Wikimedia's Germany chapter for organizing this! See you there, Sumana Harihareswara

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