Wikitech-l April 2011

wikitech-l@lists.wikimedia.org

99 participants
94 discussions

Registration open for the Hackathon in Berlin, May 13-15
by Daniel Kinzler 13 Apr '11

13 Apr '11

Hi all! Wikimedia Germany invites anyone interested in improving MediaWiki to come and join us at or third developer meet-up. Like the last two years, it's going to be awesome! Unlike the last two years, there will be more hacking and less talking - it'll be a Hackathon, not a BarCamp. We'll meet on May 13 to 15, in Berlin, on the 4th floor of the betahaus coworking space <http://betahaus.de/>. There will not be an entrance fee, but registration is mandatory and now open: <http://de.amiando.com/hackathon2011>. Registration will close on April 10. If you like to attend, please register in time! More information can be found at <http://www.mediawiki.org/wiki/Berlin_Hackathon_2011>. The Berlin Hackathon 2011 is an opportunity for MediaWiki hackers to come together, squash bugs and write crazy new features. Our main focus this time around will probably be: * Improving usability / accessibility * Interactive Maps * Fixing the parser * WMF Ops (new data center, virtualization) * Supporting the Wiki Loves Monuments image hunt * Squashing bugs If you have different ideas, please let us know: <http://www.mediawiki.org/wiki/Berlin_Hackathon_2011#Topics> The Hackathon will be hosting the Language committee and Wiki loves Monuments group. There is a limited number of seats reserved for these groups and if you belong to one of them, you should receive an invitation code soon. If you have any doubts or questions, contact us at <hackathon(a)wikimedia.de>. We’re excited to see you in Berlin, your Hackathon Team Daniel Kinzler (Program Coordinator) Nicole Ebber (Logistics) Cornelius Kibelka (Assistant)

3 3

Syntax-highlighting JS & CSS code editor gadget embedding Ace
by Brion Vibber 13 Apr '11

13 Apr '11

While pondering some directions for rapid prototyping of new UI stuff, I found myself lamenting the difficulty of editing JS and CSS code for user/site scripts and gadgets: * lots of little things to separately click and edit for gadgets * no syntax highlighting in the edit box * no indication of obvious syntax errors, leading to frequent edit->preview cycles (especially if you have to turn the gadget back off to edit successfully!) * no automatic indentation! * can't use the tab key Naturally, I thought it might be wise to start doing something about it. I've made a small gadget script which hooks into editing of JS and CSS pages, and embeds the ACE code editor (http://ace.ajax.org -- a component of the Cloud9 IDE, formerly Skywriter formerly Mozilla Bespin). This doesn't fix the usability issues in Special:Gadgets, but it's a heck of a lot more pleasant to edit the gadget's JS and CSS once you get there. :) The gadget is available on www.mediawiki.org on the 'Gadgets' tab of preferences. Note that I'm currently loading the ACE JavaScript from toolserver.org, so you may see a mixed-mode content warning if you're editing via secure.wikimedia.org. (Probably an easy fix.) Go try it out! http://www.mediawiki.org/wiki/MediaWiki:Gadget-CodeEditor.js IE 8 kind of explodes and I haven't had a chance to test IE9 yet, but it seems pretty consistently nice on current Firefox and Chrome and (barring some cut-n-paste troubles) Opera. I'd really love to be able to use more content-specific editing tools like this, and using Gadgets is a good way to make this sort of tool available for testing in a real environment -- especially once we devise some ways to share gadgets across all sites more easily. I'll be similarly Gadget-izing the SVG-Edit widget that I've previously done as an extension so folks can play with it while it's still experimental, but we'll want to integrate them better as time goes on. -- brion

6 8

Report on Monday's Bug Triage meeting
by mhershberger＠wikimedia.org 13 Apr '11

13 Apr '11

TL;DR Many older parser bugs were pushed to the new parser. However, several, mostly newer, bugs were assigned to be worked on now. To contribute to the new call for bugs, read <http://hexm.de/20>. This past Monday, I held a bug triage meeting with WMF developers to cover Parser bugs that I and other participants on this list had marked for triage. There were 27 bugs in total. Because of the open-ended nature of the call for bugs, we ended up with a fair number of “oldie-but-goodie” bugs. With Brion's parser rewrite currently being planned, this meant that a fair number of bugs were easy to shrug off. If we've lived with the pain so far, the rationale is, why go through they horrible pain of fixing it in the current parser when a more maintainable parser is just around the corner. Still, it was helpful to look at these older bugs to see the sort of problems that need to be addressed in the parser rewrite. The bugs that we decided it would be better to address in the new parser were the following: Preceding text and single apostrophes are not included in links http://bugzilla.wikimedia.org/468 Incorrect parsing of table headings and cells on the same line http://bugzilla.wikimedia.org/549 [[#foo|]], [[/bar|]] should be equivalent to [[#foo|foo]], [[/bar|bar]] (new use of "pipe trick") http://bugzilla.wikimedia.org/845 Newline as list item terminator is troublesome http://bugzilla.wikimedia.org/1115 pre over multiple lines in lists http://bugzilla.wikimedia.org/1581 Need method for multiparagraph list items, continuing numbered lists, and assigning specific numbers to list items http://bugzilla.wikimedia.org/1584 Allow one blank line in list environments http://bugzilla.wikimedia.org/9342 Automatic nbsp is inserted even into XHTML attributes, including style http://bugzilla.wikimedia.org/3158 The newline added to a template, magic word, variable, or parser function that returns line-start wikicode formatting (*#:;) causes unexpected parsing http://bugzilla.wikimedia.org/12974 Leading spaces in <pre> block render incorrectly when block preceded by another <pre> http://bugzilla.wikimedia.org/3230 Blank lines at the top of an article should be ignored http://bugzilla.wikimedia.org/4161 Single newlines sometimes create paragraphs http://bugzilla.wikimedia.org/9207 Block element written inline splits multiline paragraphs http://bugzilla.wikimedia.org/5718 Linebreaks are mishandled in <blockquote> and <li> http://bugzilla.wikimedia.org/6200 Multiline tags in lists should be output more intelligently http://bugzilla.wikimedia.org/9996 Bold/italic markup handled differently depending on leading whitespace http://bugzilla.wikimedia.org/18765 post expand size counted multiple times for nested transclusions http://bugzilla.wikimedia.org/13260 Additionally, Brion punted this bug to the new rich text editor he has planned since the problem is seen mostly in copy-and-pasted URLs: External URL syntax cannot handle square brackets http://bugzilla.wikimedia.org/3695 One bug was dismissed as WONTFIX with the justification that the reporter had a certain behavior in mind for the behavior of the parser when he wrote ''''lots of quotes'''' but that while the parser acted consistently, it didn't act in his preferred manner Single quote inside triple quote bold (''') parsing error http://bugzilla.wikimedia.org/13227 Still, all was not lost. For example, Neil saw this ancient bug as an opportunity to get closer to the gnarly internals of MediaWiki. tilde signatures inside nowiki tags sometimes get expanded (<includeonly><nowiki>~~~~</nowiki></includeonly>) http://bugzilla.wikimedia.org/93 Sam saw this bug and decided it looked like it would be easy to test and apply the included patch: Transcluded special pages expose strip markers when they output parsed messages http://bugzilla.wikimedia.org/16129 Finally, Tim saw these two relatively recent bugs and decided he would investigate them further and hopefully fix them: DOM preprocessor barfs on headings inserted by parser functions http://bugzilla.wikimedia.org/21844 {{fullurl:}} does not urlencode passed querystring http://bugzilla.wikimedia.org/27972 To see the notes from the Bug Triage (thanks, Sumana!) visit http://etherpad.wikimedia.org/BugTriage. Please see my earlier email to the list (http://hexm.de/20) if you'd like to contribute to this coming week's triage. Mark.

1 0

ShortURL for Non Latin Mediawiki sites
by Srikanth Lakshmanan 13 Apr '11

13 Apr '11

Hi all, Sharing of URLs of non latin wiki's werent really easy and when copy pasting we get the unicode numerals in the URL like http://ta.wikipedia.org/wiki/%E0%AE%B5%E0%AE%BF%E0%AE%95%E0%AF%8D%E0%AE%95%… en:User:Mountain had come up with a shortify project[1] and thanks to Yuvipanda its now live on Tamil Wikipedia. All pages have a link on the right side of article title. http://tawp.in/r/262 is the same link and is being displayed there. The feedback from the community is to have this hosted by Wikimedia itself as it would be more reliable than individual running it. So there came the idea of a mediawiki extension and hence Shorturl extension[2] was born by some really quick work by Yuvipanda.Its live here[3].(See the toolbox for short URL) While this may be a small thing, it does help non latin wiki's a lot.Having it in the extension form is more reliable even though the URL length goes up, but still its worthy.The URL length can be shortened with mod_rewrite rules on. I would ideally like this to be used across non latin wikimedia properties as it helps these projects(like echoed here[4]). Please let me know how to do this. Bugs on wikimedia bugzilla will do? Feedback appreciated. [1] https://github.com/mountain/shortify [2] http://www.mediawiki.org/wiki/Extension:ShortUrl [3] http://wiki.busroutes.in/wiki/Chennai [4] http://lists.wikimedia.org/pipermail/wikimediaindia-l/2011-March/002699.html <http://lists.wikimedia.org/pipermail/wikimediaindia-l/2011-March/002699.html> Regards Srikanth.L

7 9

Actions and Special Pages
by Happy-melon 12 Apr '11

12 Apr '11

In the beginning, there was Article.php. And the Article class had methods like Article::view(), Article::delete(), Article::protect(), etc. And the fundamental codeflow of Mediawiki consisted of something along the lines of: $article = new Article( $title ); $action = wfGetTheActionSomehow(); $article->$action(); Over time Article has grown and bloated to become our third largest class (after ZhConversion and Parser). Several of its action methods have been spun out to separate files (EditPage.php, ProtectionForm.php and HistoryPage.php, among others). It's long overdue that this process be carried through to its natural conclusion with all action methods spun out into some new structure. There are essentially two competing possibilities for structuring this, and they reflect the two parallel systems we have for "doing things other than viewing" to a wiki. One is action parameters, and the other is special pages. We have action=edit, or Special:MovePage, for instance; they have a similar function but different structure. We have action=delete to get rid of stuff, but then Special:Undelete to bring it back again. Special:Whatlinkshere and action=history are another pair of pages which have very similar principles (getting data that relates to a given page) but different implementations. For either case in the backend I would think we'd want to create an ActionPage base class and an EditActionPage from that, which looks internally rather like a SpecialPage construct, might even subclass it. I'd like to ask people's opinions about which they think would work better in the frontend for, say, editing or protecting. If people think it would be better as a special page we'd make http://foo.example.com/w/index.php?title=Bar&action=edit a hard redirect to Special:Edit/Bar; that has the significant advantage of being able to be formed as an internal link. Conversely if we'd like to keep it an action it would make sense to redirect Special:MovePage/Bar back to ?title=Bar&action=move. Or is something more exotic like [[Action:Edit/Bar]] a possibility? Thoughts? --HM

10 13

MediaWiki security release 1.16.3
by Tim Starling 12 Apr '11

12 Apr '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I would like to announce the release of MediaWiki 1.16.3, which is a security release. Three security issues were discovered. Masato Kinugawa discovered a cross-site scripting (XSS) issue, which affects Internet Explorer clients only, and only version 6 and earlier. Web server configuration changes are required to fix this issue. Upgrading MediaWiki will only be sufficient for people who use Apache with AllowOverride enabled. Due to the diversity of uploaded files that we allow, MediaWiki does not guarantee that uploaded files will be safe if they are interpreted by the client as some arbitrary file type, such as HTML. We rely on the web server to send the correct Content-Type header, and we rely on the web browser to respect it. This XSS issue arises due to IE 6 looking for a file extension in the query string of the URL (i.e. after the "?"), if no extension is found in path part of the URL. Masato Kinugawa discovered that the file extension in the path part can be hidden from IE 6 by substituting the "." with "%2E". To fix this issue, configure your web server to deny requests with URLs that have a path part ending in a dot followed by a dangerous file extension. For example, in Apache with mod_rewrite: RewriteEngine On RewriteCond %{QUERY_STRING} \.[a-z]{1,4}$ [nocase] RewriteRule . - [forbidden] Upgrading MediaWiki is necessary to fix this issue in dynamically-generated content. This issue is easier to exploit using dynamically generated content, since it requires no special privileges. Accounts on both public and private wikis can be compromised by clicking a malicious link in an email or website. For more details, see bug 28235. Wikipedia user Suffusion of Yellow discovered a CSS validation error in the wikitext parser. This is an XSS issue for Internet Explorer clients, and a privacy loss issue for other clients since it allows the embedding of arbitrary remote images. For more details, see bug 28450. MediaWiki developer Happy-Melon discovered that the transwiki import feature neglected to perform access control checks on form submission. The transwiki import feature is disabled by default. If it is enabled, it allows wiki pages to be copied from a remote wiki listed in $wgImportSources. The issue means that any user can trigger such an import to occur. For more details, see bug 28449. The localisations were updated using content from translatewiki.net. ********************************************************************** Download: http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.3.tar.gz Patch to previous version (1.16.2), without interface text: http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.3.patch.gz Interface text changes: http://download.wikimedia.org/mediawiki/1.16/mediawiki-i18n-1.16.3.patch.gz GPG signatures: http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.3.tar.gz.sig http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.3.patch.gz.sig http://download.wikimedia.org/mediawiki/1.16/mediawiki-i18n-1.16.3.patch.gz… Public keys: https://secure.wikimedia.org/keys.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAk2jxbAACgkQgkA+Wfn4zXn38gCWISDEZuC+Ap3Z4aBfibnuNSU1 EgCfeL2lo/4XtCuoKOwah0YbuaHyf5I= =S2JZ -----END PGP SIGNATURE-----

1 0

回复： MediaWiki security release 1.16.3
by GMAIL信箱 12 Apr '11

12 Apr '11

库ukulm仍啊空说八宝山的人飞蛾原信息主题： [Wikitech-l] MediaWiki security release 1.16.3 发件人： Tim Starling <tstarling(a)wikimedia.org> 日期： 2011/04/12 11:24 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I would like to announce the release of MediaWiki 1.16.3, which is a security release. Three security issues were discovered. Masato Kinugawa discovered a cross-site scripting (XSS) issue, which affects Internet Explorer clients only, and only version 6 and earlier. Web server configuration changes are required to fix this issue. Upgrading MediaWiki will only be sufficient for people who use Apache with AllowOverride enabled. Due to the diversity of uploaded files that we allow, MediaWiki does not guarantee that uploaded files will be safe if they are interpreted by the client as some arbitrary file type, such as HTML. We rely on the web server to send the correct Content-Type header, and we rely on the web browser to respect it. This XSS issue arises due to IE 6 looking for a file extension in the query string of the URL (i.e. after the "?"), if no extension is found in path part of the URL. Masato Kinugawa discovered that the file extension in the path part can be hidden from IE 6 by substituting the "." with "%2E". To fix this issue, configure your web server to deny requests with URLs that have a path part ending in a dot followed by a dangerous file extension. For example, in Apache with mod_rewrite: RewriteEngine On RewriteCond %{QUERY_STRING} \.[a-z]{1,4}$ [nocase] RewriteRule . - [forbidden] Upgrading MediaWiki is necessary to fix this issue in dynamically-generated content. This issue is easier to exploit using dynamically generated content, since it requires no special privileges. Accounts on both public and private wikis can be compromised by clicking a malicious link in an email or website. For more details, see bug 28235. Wikipedia user Suffusion of Yellow discovered a CSS validation error in the wikitext parser. This is an XSS issue for Internet Explorer clients, and a privacy loss issue for other clients since it allows the embedding of arbitrary remote images. For more details, see bug 28450. MediaWiki developer Happy-Melon discovered that the transwiki import feature neglected to perform access control checks on form submission. The transwiki import feature is disabled by default. If it is enabled, it allows wiki pages to be copied from a remote wiki listed in $wgImportSources. The issue means that any user can trigger such an import to occur. For more details, see bug 28449. The localisations were updated using content from translatewiki.net. ********************************************************************** Download: http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.3.tar.gz Patch to previous version (1.16.2), without interface text: http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.3.patch.gz Interface text changes: http://download.wikimedia.org/mediawiki/1.16/mediawiki-i18n-1.16.3.patch.gz GPG signatures: http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.3.tar.gz.sig http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.3.patch.gz.sig http://download.wikimedia.org/mediawiki/1.16/mediawiki-i18n-1.16.3.patch.gz… Public keys: https://secure.wikimedia.org/keys.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAk2jxbAACgkQgkA+Wfn4zXn38gCWISDEZuC+Ap3Z4aBfibnuNSU1 EgCfeL2lo/4XtCuoKOwah0YbuaHyf5I= =S2JZ -----END PGP SIGNATURE----- _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

1 0

Good mediawiki custom extension writing tutorial
by Tod 11 Apr '11

11 Apr '11

Is there something like a hello world tutorial to get me going? Thanks - Tod

2 1

Aquestion about templates parsing and caching
by Alex Brollo 11 Apr '11

11 Apr '11

I'd like to know something more about template parsing/caching for performance issues. My question is: when a template is called, it's wikicode, I suppose, is parsed and translated into "something running" - I can't imagine what precisely, but I don't care so much about (so far :-) ). If a second call comes to the server for the same template, but with different parameters, the template is parsed again from scratch or something from previous parsing is used again, so saving a little bit of server load? If the reply is "yes", t.i. if the "running code" of the whole template is somehow saved and cached, ready to be used again with new parameters, perhaps it could be a good idea to build templates as "librares of different templates", using the name of the template as a "library name" and a parameter as the name of "specific function"; a simple #switch could be used to use the appropriate code of that "specific function". On the contrary, if nothing is saved, there would be good reasons to keep the template code as simple as possible, and this idea of "libraries" would be a bad one. Alex

8 15

Re: [Wikitech-l] [Mediawiki-l] Sidebar Customization
by Daniel Friesen 09 Apr '11

09 Apr '11

On 11-04-08 09:49 AM, Henny Savenije wrote: > At 12:45 AM 4/9/2011, Trevor wrote: >> Take a look at the Vector extension. It offers a variety of >> progressive enhancements for the Vector skin. > I tried to install that but I get a blank page. > _ _ > (o) (o) > oOOO----(_)----OOOo--- > Henny (Lee Hae Kang) By any chance are you running 1.16? The Vector extension is only compatible with 1.17+. For 1.16 you need to use the UsabilityInitiative extension that the Vector extension was split out from around 1.17. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

1 0

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

2026

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 April 2011