Wikitech-l April 2011

wikitech-l@lists.wikimedia.org

99 participants
90 discussions

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 11 Apr '11

11 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信箱 11 Apr '11

11 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 08 Apr '11

08 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

Moving math/texvc to Math extension for 1.18 (packagers take note)
by Brion Vibber 08 Apr '11

08 Apr '11

I've taken the liberty of moving most of the math guts out of MediaWiki core into its own Math extension: https://bugzilla.wikimedia.org/show_bug.cgi?id=14202 http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85706 We meant to do this years ago -- I even got partway through it once but got held up on the horrid Special:Preferences system we had back in the day and never finished it. The modern Preferences class is a lot more flexible, and I was able to just grab the function that sets up that portion of the form and move it over. Yay! There are a few cleanup bits still to do; I didn't want to dive into the message files just yet. There are some legacy interfaces on Language for getting the math option names, so that'll need a little more fixin' to remove those (the strings _should_ all be in the regular message area now) and then break the message files out. People doing third-party packages of MediaWiki should take note: the texvc subprogram source will live in the extension now, not core, so build scripts for 'mediawiki-math' packages will need to be updated. -- brion

1 0

Narayam User Interface Improvements
by Trevor Parscal 08 Apr '11

08 Apr '11

When Roan Kattouw reviewed, and then rewrote most of the Narayam extension, I reviewed his code, and found many things about the user interface that could be, and need to be improved. I have both some observations and some suggestions, expressed in the attached PDF. The exact design I'm proposing isn't a requirement, but hopefully is provides a starting point for a way to get this extension's user interface where we need it to be. - Trevor

6 10

WMDE offers a contract for implementing GraphServe (part of next-gen CatScan)
by Daniel Kinzler 08 Apr '11

08 Apr '11

Hi all! Wikimedia Deutschland is offering a contract for implementing the GraphServ component for our Graph Processor project. Anyone interested is invited to apply, the official call for bids is at <http://wikimedia.de/wiki/Ausschreibung/GraphServ>. The Graph Processor project aims to develop an infrastructure for rapidly analyzing and evaluating Wikipedia's category structure. It's supposed to become part of the Toolserver infrastructure (and eventually, the WMF search cluster) that allows CatScan-like queries to run in under a second instead of minutes. The contract offered here covers the implementation of the GraphServ component, which is to function as a service by which applications can access the category structures of different wikis, similar to the way a database server would provide access to information stored in databases. Technically, GraphServ is a server that manages TCP connections and attaches them to instances of GraphCore, which do the actual processing of the category structures <https://github.com/jkroll20/graphcore/blob/master/spec.rst>. The server will be accessed by applications via client libraries written in PHP, Python, etc, which are not in scope of the contract but will be developed in parallel by Wikimedia Deutschland. A rough specification of the GraphServ component along with requirements for the implementations can be found at <http://wikimedia.de/wiki/Ausschreibung/GraphServ/Spec>. Note that GraphServ will be released as Open Source Software. While Wikimedia Deutschland will be the copyright holder for the software developed under contract, we will include the name of the actual authors in the copyright notice. Applications should include the following: * The applicant's prior experience with designing and implementing client/server software, as well as any other relevant qualifications * An overview of the intended architecture of the implementation and the technologies used, along with a rationale for choosing this architecture and technologies over others. * A rough road map of the implementation, documentation and testing phases, with the appropriate mile stones. * Estimate of working hours needed * Time frame for the implementation (calendar weeks) * Total expected cost, including taxes Please send your application to <technik(a)wikimedia.de> by April 29. Cheers, Daniel PS: please forward this to anyone you think could be interested. thanks!

1 0

Open call for Parser bugs
by mhershberger＠wikimedia.org 07 Apr '11

07 Apr '11

Starting with this coming Monday's bug triage, I want to try and make sure the community's voice is heard. In order to do that, I've created the “triage” keyword in Bugzilla. Every week, I'll announce a theme and use this keyword to keep track of the bugs that will be handled in the meeting. As we discuss the bug, it will be modified, probably assigned to a developer, and the “triage” keyword removed. Some people may see this as bug-spam, but I'd like to keep the email notifications on so that people who have expressed an interest will know that we're giving the bugs some love. This week, I'm going to focus on Parser-related bugs. There are currently 10 bugs on the with the “triage” keyword applied. A bug triage meeting needs about 30 bugs, so I have room for about 20 more right now. I'll be adding to the list before Monday, but this is your chance to get WMF's developers talking about YOUR favorite parser bug by adding the “triage” keyword. I will reserve the right to remove the “triage” keyword — especially if the list becomes unwieldy, or if the bug has nothing to do with parsing — but I wanted to start to open up the triage process a bit more and begin to provide a way for the community to participate in these meetings. Mark.

5 5

← Newer
1
2
3
4
5
6
7
8
9
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 April 2011