Wikitech-l April 2010

wikitech-l@lists.wikimedia.org

64 participants
46 discussions

by Tim Starling

I'm planning on updating Wikimedia's copy of MediaWiki to the version we are calling 1.16wmf4, a few hours from now. There will be a brief period of read-only time (about 15 minutes) while I do a schema update. If the site breaks, then please report it on #wikimedia-tech on Freenode. -- Tim Starling

14 years

2010-03-11 01:10:08: enwiki Checksumming pages-meta-history.xml.bz2 :D

by Tomasz Finc

New full history en wiki snapshot is hot off the presses! It's currently being checksummed which will take a while for 280GB+ of compressed data but for those brave souls willing to test please grab it from http://download.wikipedia.org/enwiki/20100130/enwiki-20100130-pages-meta-hi… and give us feedback about its quality. This run took just over a month and gained a huge speed up after Tims work on re-compressing ES. If we see no hiccups with this data snapshot, I'll start mirroring it to other locations (internet archive, amazon public data sets, etc). For those not familiar, the last successful run that we've seen of this data goes all the way back to 2008-10-03. That's over 1.5 years of people waiting to get access to these data bits. I'm excited to say that we seem to have it :) --tomasz

14 years

application settings for my extension

by Prince Gerald Albert - ERS, HCL Tech

Hi Geeks, I want to know the best option to store a application wide setting / options in mediawiki for an custom developed extension. Say for example in my extension I need to create a global variable, if it does not exists and reuse it. I can't keep this in Localsettings.php file, since I need to generate on the fly (once) and use it throughout the application Right now it is one option and I may require to create multiple options and use it, please guide me or give some links to go through thanks, Prince Gerald A DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. -----------------------------------------------------------------------------------------------------------------------

14 years

Template collapsing in Citron - default text?

by Tisza Gergő

The soon-to-come third version of the usability extension, Citron, will be able to collapse templates in the edit window: http://usability.wikimedia.org/w/index.php?title=File:Updated_Citron_templa… The problem with this approach is that sometimes collapsing is harmful to the readability of the wikitext. For example, huwiki has a template which looks like this: "Water is generally thought to be wet, {{citation needed|text=though some argue it is actually dry}}." That is, it can be used to select a specific part of the text and mark it as problematic. There are many similar templates which annotate a section of the text without breaking its flow; of you collapse the template, the text becomes much harder to read. The reason I'm asking about this is that we're just about to reorganize some template parameter naming conventions, and would like to consider future compatibility with Citron, and the only solution to the above problem I can think of is to have a whitelist of template parameter names whose values will be visible even in a collapsed state. (Being able to define such parameters with per-template settings would be more flexible, but I suppose it is very expensive to do so.) So, is there a chance Citron will have such a feature in the future and there is value in giving all such parameters a common, distinctive, non-numeric name?

14 years

MediaWiki security update: 1.15.3 and 1.16.0beta2

by Tim Starling

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is a security and bugfix release of MediaWiki 1.15.3 and MediaWiki 1.16.0beta2. MediaWiki was found to be vulnerable to login CSRF. An attacker who controls a user account on the target wiki can force the victim to log in as the attacker, via a script on an external website. If the wiki is configured to allow user scripts, say with "$wgAllowUserJs = true" in LocalSettings.php, then the attacker can proceed to mount a phishing-style attack against the victim to obtain their password. Even without user scripting, this attack is a potential nuisance, and so all public wikis should be upgraded if possible. Our fix includes a breaking change to the API login action. Any clients using it will need to be updated. We apologise for making such a disruptive change in a minor release, but we feel that security is paramount. For more details see https://bugzilla.wikimedia.org/show_bug.cgi?id=23076 ********************************************************************** 1.15.3 ********************************************************************** Full release notes: http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_15_3/phase3/RELEASE-NO… Download: http://download.wikimedia.org/mediawiki/1.15/mediawiki-1.15.3.tar.gz Patch to previous version (1.15.2), without interface text: http://download.wikimedia.org/mediawiki/1.15/mediawiki-1.15.3.patch.gz Interface text changes: http://download.wikimedia.org/mediawiki/1.15/mediawiki-i18n-1.15.3.patch.gz GPG signatures: http://download.wikimedia.org/mediawiki/1.15/mediawiki-1.15.3.tar.gz.sig http://download.wikimedia.org/mediawiki/1.15/mediawiki-1.15.3.patch.gz.sig http://download.wikimedia.org/mediawiki/1.15/mediawiki-i18n-1.15.3.patch.gz… Public keys: https://secure.wikimedia.org/keys.html ********************************************************************** 1.16.0beta2 ********************************************************************** Full release notes: http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_16_0beta2/phase3/RELEA… Download: http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.0beta2.tar.gz Patch to previous version (1.16.0beta1), without interface text: http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.0beta2.patch.gz Interface text changes: http://download.wikimedia.org/mediawiki/1.16/mediawiki-i18n-1.16.0beta2.pat… GPG signatures: http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.0beta2.tar.gz.s… http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.0beta2.patch.gz… http://download.wikimedia.org/mediawiki/1.16/mediawiki-i18n-1.16.0beta2.pat… Public keys: https://secure.wikimedia.org/keys.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAku72c0ACgkQgkA+Wfn4zXmmywCgg93Qn9fFiBZmMjfFfRXtQAAY /2kAn3mnedysUErnHt59Va2rGHuSJUzf =Ytqc -----END PGP SIGNATURE-----

14 years

Re: [Wikitech-l] Mediawiki extensions and Windows 2003 server

by Makelesi Kora-Gonelevu

AccessControl and GroupPermissionsManager. I have MediaWiki 1.15 and IIS6. On Sun, Apr 4, 2010 at 9:22 AM, Siebrand Mazeland <s.mazeland(a)xs4all.nl>wrote: > From: Makelesi Kora-Gonelevu > Sent: Saturday, April 03, 2010 10:58 PM > > I've tried installing a number of extensions on a Windows 2003 server but > they dont seem to work. Although i've successfully installed it onto Linux. > I think this has to do with the Read-only attribute thats inbuilt into the > Windows 2003 server. > > Anyone out there ever come across this problem? If yes how did you work > your > way around it? Looking forward to any responses. > > [sm] Please provide more details on which extensions and which version of > MediaWiki. I have a MediaWiki 1.17alpha (r64216) running fine on IIS6 with > Windows Server 2003 (PHP 5.2.12/MySQL 5.1.43) and the following extensions: > AdminLinks, ConfirmAccount, ContributionScores, ExpandTemplates, Renameuser, > ReplaceText, SemanticDrilldown, SemanticForms, UserMerge, BreadCrumbs, > CharInsert, SemanticMediaWiki, SyntaxHighlight_geshi, Widgets, CleanChanges, > LiquidThreads, NewUserMessage, SemanticResultFormats, UsabilityInitiative > (Vector/WikiEditor) > > Siebrand > > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l >

14 years

GSoC proposal for texvc port---comments?

by Damon Wang

Hello everyone, For some reason, I keep screwing up this message. I'm sorry if the other copies actually did get through and are spamming the list now. I didn't see it in my inbox or in the archives or on Gmane this morning, so I thought I'd try again. Could someone reply, just to let me know this actually did get through? I'd appreciate that. Yours, Damon Wang ---------- Forwarded message ---------- From: Damon Wang <damon.wang(a)gmail.com> Date: 2010/4/4 Subject: GSoC proposal for texvc port---comments? To: wikitech-l(a)lists.wikimedia.org Hello everyone, Thanks to everyone in that 58-message long thread for taking the time to discuss my GSoC proposal to port texvc from OCaml to Python. After reading the replies, I've written a draft of my GSoC proposal to port texvc from OCaml to Python. It's available at http://www.mediawiki.org/wiki/User:damonwang I'd appreciate any comments, especially replies to the questions in the notes, on the associated discussion page. Again, thank you all for taking the time to help me refine this project. Yours, Damon Wang P.S. Is it necessary to submit another copy to Google immediately? I realize I have to go through their web form eventually, but it seems like the wiki and this mailing list provide a much more flexible way of discussing the project. Can I keep it on the wiki until 8 April and then submit a final draft? P.P.S. Mr. Lanphier, you will probably get this twice because I got the wikitech-l address wrong the first time. Sorry, won't happen again.

14 years

GIF Thumbnailing re-enabled

by Andrew Garrett

Hi all, I found the problem which caused GIF thumbnailing to thumbnail only the first frame of animated GIFs (we'd set $wgMaxAnimatedGifArea to 1 in our debugging before disabling it). GIF thumbnailing is now back on again. Let me know if there are any problems with it. -- Andrew Garrett http://werdn.us/

14 years

Cite extension- extra functionality

by Nimish Gautam

Hey all, I wanted to change the "cite" extension to have some extra functionality. As citations have gotten more common, I've noticed an emerging use case where people will copy and paste text from wikipedia to HTML-enabled tools such as email clients or IM clients to share information. Unfortunately, those citation links just link to anchors on the page and don't provide anything useful when copied/pasted. Appending the full page's URL to those links would take like 20 seconds, make them functional, but would add extra markup to every page. Anyone have any other good reasons why we shouldn't do this? -Nimish

14 years

GSoC project advice: port texvc to Python?

by Damon Wang

Hello everyone, I'm interested in porting texvc to Python, and I was hoping this list here might help me hash out the plan. Please let me know if I should take my questions elsewhere. Roughly, my plan of attack would be something like this: 1. Collect test cases and write a testing script Thanks to avar from #wikimedia, I already have the <math>...</math> bits from enwiki and dewiki. I would also construct some simpler ones by hand to test each of the acceptable LaTeX commands. Would there be any possibility of logging the input seen by texvc on a production instance of Mediawiki, so I could get some invalid input submitted by actual users? This could also be useful to future maintainers for regression testing. 2. Implement an AMS-TeX validator I'll probably use PLY because it's rumored to have helpful debugging features (designed for a first-year compilers class, apparently). ANTLR is another popular option, but this guy http://www.bearcave.com/software/antlr/antlr_expr.html thinks it's complicated and hard to debug. I've never used either, so if anyone on this list knows of a good Python parsing package I'd welcome suggestions. 3. Port over the existing tex->dvi->png rendering. This is probably just a few calls into the subprocess module. Yeah, I just jinxed it. 4. Add HTML rendering to texvc and test script I don't even understand how the existing texvc decides whether HTML is good enough. It looks like the original programmer just decreed that certain LaTeX commands could be rendered to HTML, and defaults to PNG if it sees anything not on that list. How important is this feature? 5. Repackage the entire Math thing as an extension I might do this if I have time left at the end. I'm sure the project will change over the summer. Python doesn't have parsing just locked right down the way C does with flex/bison, but there are some good options, I have the most experience with it, and I think I'd be able to complete the port faster in Python than in either of the other languages. I was tempted at first to port to PHP, to conform with the rest of Mediawiki, but there don't seem to be any good parsing packages for PHP. (Please tell me if that's wrong.) I'd appreciate any advice or criticism. Since my only previous experience has been using Wikipedia and setting up a test Mediawiki instance for my ACM chapter, I'm only just now learning my way around the code base and it's not always evident why things were done as they are. Does this look like a reasonable and worthwhile project? Yours, Damon Wang P.S. Some of you may remember me on IRC a couple of days ago getting a little panicky about not knowing OCaml, but I'm a bit more hopeful now after looking around the source. I definitely have to keep the OCaml manual open for reference, but I've written Scheme, Common Lisp, and Haskell before, so I think I might be able to fake it. These are just Famous Last Words waiting to happen, I know.

14 years

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 2010