Wikitech-l April 2012

wikitech-l@lists.wikimedia.org

152 participants
192 discussions

Database dumps
by Byrial Jensen 17 Apr '25

17 Apr '25

Until some weeks ago http://dumps.wikimedia.org/backup-index.html used to show 4 dumps in progress at the same time. That meant that new database dumps normally was available within about 3 weeks for all databases except for enwiki and maybe dewiki where the dump process due to size took longer time. However the 4 dumps processes at one time become 3 some weeks ago. And after massive failures at June 4, only one dump has been in progress at the same time. So at the current speed it will take several months to come thru all dumps. Is it possible to speed up the process again using several dump processes at the same time? Thank you, Byrial

3 2

User-Agent:
by Domas Mituzas 17 Apr '25

17 Apr '25

Hi! from now on specific per-bot/per-software/per-client User-Agent header is mandatory for contacting Wikimedia sites. Domas

19 61

EBNF grammar project status?
by Steve Bennett 01 Apr '25

01 Apr '25

What's the status of the project to create a grammar for Wikitext in EBNF? There are two pages: http://meta.wikimedia.org/wiki/Wikitext_Metasyntax http://www.mediawiki.org/wiki/Markup_spec Nothing seems to have happened since January this year. Also the comments on the latter page seem to indicate a lack of clear goal: is this just a fun project, is it to improve the existing parser, or is it to facilititate a new parser? It's obviously a lot of work, so it needs to be of clear benefit. Brion requested the grammar IIRC (and there's a comment to that effect at http://bugzilla.wikimedia.org/show_bug.cgi?id=7 ), so I'm wondering what became of it. Is there still a goal of replacing the parser? Or is there some alternative plan? Steve

26 217

Missing Section Headings
by Marc Riddell 13 Sep '24

13 Sep '24

Hello, I have been a WP editor since 2006. I hope you can help me. For some reason I no longer have Section Heading titles showing in the Articles. This is true of all Headings including the one that carries the Article subject's name. When there is a Table of Contents, it appears fine and, when I click on a particular Section, it goes to that Section, but all that is there is a straight line separating the Sections. There is also no button to edit a Section. If I edit the page and remove the "== ==" markers from the Section Titles, the Title then shows up, but not as a Section Heading. Also, I don't have any Date separators on my Want List. This started 2 days ago. Any thoughts? Thanks, Marc Riddell [[User:Michael David]]

10 11

MediaWiki 1.19.0beta2
by Sam Reed 09 May '14

09 May '14

I'm happy to announce the availability of the second beta release of the new MediaWiki 1.19 release series. Please try it out and let us know what you think. Don't run it on any wikis that you really care about, unless you are both very brave and very confident in your MediaWiki administration skills. MediaWiki 1.19 is a large release that contains many new features and bug fixes. This is a summary of the major changes of interest to users. You can consult the RELEASE-NOTES-1.19 file for the full list of changes in this version. Five security issues were discovered. It was discovered that the api had a cross-site request forgery (CSRF) vulnerability in the block/unblock modules. It was possible for a user account with the block privileges to block or unblock another user without providing a token. For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=34212 It was discovered that the resource loader can leak certain kinds of private data across domain origin boundaries, by providing the data as an executable JavaScript file. In MediaWiki 1.18 and later, this includes the leaking of CSRF protection tokens. This allows compromise of the wiki's user accounts, say by changing the user's email address and then requesting a password reset. For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=34907 Jan Schejbal of Hatforce.com discovered a cross-site request forgery (CSRF) vulnerability in Special:Upload. Modern browsers (since at least as early as December 2010) are able to post file uploads without user interaction, violating previous security assumptions within MediaWiki. Depending on the wiki's configuration, this vulnerability could lead to further compromise, especially on private wikis where the set of allowed file types is broader than on public wikis. Note that CSRF allows compromise of a wiki from an external website even if the wiki is behind a firewall. For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=35317 George Argyros and Aggelos Kiayias reported that the method used to generate password reset tokens is not sufficiently secure. Instead we use various more secure random number generators, depending on what is available on the platform. Windows users are strongly advised to install either the openssl extension or the mcrypt extension for PHP so that MediaWiki can take advantage of the cryptographic random number facility provided by Windows. Any extension developers using mt_rand() to generate random numbers in contexts where security is required are encouraged to instead make use of the MWCryptRand class introduced with this release. For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=35078 A long-standing bug in the wikitext parser (bug 22555) was discovered to have security implications. In the presence of the popular CharInsert extension, it leads to cross-site scripting (XSS). XSS may be possible with other extensions or perhaps even the MediaWiki core alone, although this is not confirmed at this time. A denial-of-service attack (infinite loop) is also possible regardless of configuration. For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=35315 ********************************************************************* What's new? ********************************************************************* MediaWiki 1.19 brings the usual host of various bugfixes and new features. Comprehensive list of what's new is in the release notes. * Bumped MySQL version requirement to 5.0.2. * Disable the partial HTML and MathML rendering options for Math, and render as PNG by default. * MathML mode was so incomplete most people thought it simply didn't work. * New skins/common/*.css files usable by skins instead of having to copy piles of generic styles from MonoBook or Vector's css. * The default user signature now contains a talk link in addition to the user link. * Searching blocked usernames in block log is now clearer. * Better timezone recognition in user preferences. * Extensions can now participate in the extraction of titles from URL paths. * The command-line installer supports various RDBMSes better. * The interwiki links table can now be accessed also when the interwiki cache is used (used in the API and the Interwiki extension). Internationalization - -------------------- * More gender support (for instance in user lists). * Add languages: Canadian English. * Language converter improved, e.g. it now works depending on the page content language. * Time and number-formatting magic words also now depend on the page content language. * Bidirectional support further improved after 1.18. Release notes - ------------- Full release notes: https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob_plain;f=RE LEASE-NOTES-1.19;hb=1.19.0beta2 https://www.mediawiki.org/wiki/Release_notes/1.19 Co-inciding with these security releases, the MediaWiki source code repository has moved from SVN (at https://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3) to Git (https://gerrit.wikimedia.org/gitweb/mediawiki/core.git). So the relevant commits for these releases will not be appearing in our SVN repository. If you use SVN checkouts of MediaWiki for version control, you need to migrate these to Git. If you up are using tarballs, there should be no change in the process for you. Please note that any WMF-deployed extensions have also been migrated to Git also, along with some other non WMF-maintained ones. Please bear with us, some of the Git related links for this release may not work instantly, but should later on. To do a simple Git clone, the command is: git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git More information is available at https://www.mediawiki.org/wiki/Git For more help, please visit the #mediawiki IRC channel on freenode.net irc://irc.freenode.net/mediawiki or email The MediaWiki-l mailing list at mediawiki-l(a)lists.wikimedia.org. ********************************************************************** Download: http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.tar.gz Patch to previous version (1.19.0beta1), without interface text: http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.patch.gz Interface text changes: http://download.wikimedia.org/mediawiki/1.19/mediawiki-i18n-1.19.0beta2.patc h.gz GPG signatures: http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.tar.gz.si g http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.patch.gz. sig http://download.wikimedia.org/mediawiki/1.19/mediawiki-i18n-1.19.0beta2.patc h.gz.sig Public keys: https://secure.wikimedia.org/keys.html

5 5

Inline styles trouble on the mobile site
by Jon Robson 02 Jul '12

02 Jul '12

Hello! I thought I'd reach out to the wider wikitech community to discuss a problem we are having in the MobileFrontend extension and see if anyone can come up with a good solution. The MobileFrontend extension is increasingly getting [1] bugs [2] raised [3] which are due to inline css styles present in certain wiki articles that are written with the desktop site in mind. (Slightly off topic there is also certain content that just doesn't work on mobile [4]) To get an idea of some of the bugs that are present please see this bug [5]. Currently we are resorting to various !important hacks in a separate css file [6] but this is not sustainable and does not cover everything and ideally I would prefer that this file was not needed at all. Solutions I have thought about so far involve the following. I am yet to conclude on which is the best way to do this so would really appreciate discussion... 1) scrubbing all inline styles ######################### * in php - my worry is this would be a quite expensive operation? * in javascript (but this doesn't help people with javascript disabled) * would mean any nice mobile safe styling disappears :( 2) scrubbing certain inline styles ######################### * I could imagine us scrubbing any inline styles which have not been marked as mobile safe (e.g. anything with a class 'mobilesafe' keeps its inline style) - this at least allows editors to use pretty styles and encourages checking their styles on mobile 3) disallowing inline styles in wikitext output ################################## * this is controversial as it would restrict us to defining css rules in MediaWiki:Common.css which only admins can edit ** one could imagine pages/templates being able to maintain their own stylesheets for desktop and mobile to allow customisations ** ResourceLoader could serve the desktop or mobile stylesheet depending on the context 4) educating editors better about ensuring their styles work on mobile ############################################# I'm not sure how effective/sustainable this would be and how we'd go about doing this... but would be keen to hear your thoughts around it. [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=30887 [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=36030 [3] https://bugzilla.wikimedia.org/show_bug.cgi?id=36076 [4] https://bugzilla.wikimedia.org/show_bug.cgi?id=20030 [5] https://bugzilla.wikimedia.org/show_bug.cgi?id=35704 [6] https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/MobileFrontend…

24 58

MediaWiki to Latex Converter
by Hugo Vincent 18 Jun '12

18 Jun '12

Hi everyone, I recently set up a MediaWiki (http://server.bluewatersys.com/w90n740/) and I need to extra the content from it and convert it into LaTeX syntax for printed documentation. I have googled for a suitable OSS solution but nothing was apparent. I would prefer a script written in Python, but any recommendations would be very welcome. Do you know of anything suitable? Kind Regards, Hugo Vincent, Bluewater Systems.

6 13

Upcoming cultural heritage hackathon, autumn 2012 in Denmark
by Ole Palnatoke Andersen 16 Jun '12

16 Jun '12

Hello! Various cultural institutions in Denmark are planning a cultural heritage hackathon in the autumn. They are still in the google-doc-phase: https://docs.google.com/spreadsheet/ccc?key=0Asi52gKHCCyOdG9naG55Y2xtVnlaLU… Perhaps someone is interested in chipping in with knowledge about the MediaWiki API? Regards, Ole -- http://palnatoke.org * @palnatoke * +4522934588

4 9

Guidelines for db schema changes
by Rob Lanphier 14 Jun '12

14 Jun '12

Hi everyone, As we do more frequent deploys, it's going to become critical that we get database schema changes correct, and that we do so in a way that gives us time to prepare for said changes and roll back to old versions of the software should a deploy go poorly. This applies both to MediaWiki core and to WMF-deployed extensions. I'd like to propose that we make the following standard practice: 1. All schema changes must go through a period of being optional. For example, instead of changing the format of a column, create a new column, make all writes happen to the old and new column (if it exists) and deprecate use of the old column. Check if the new column exists before blindly assuming that it does. Only eliminate support for the old column after it's clear the schema migration has happened and there's no chance that we'll need to roll back to the old version of the software. 2. There might be cases where rule #1 will be prohibitive from a performance perspective. However, schema changes like that should be rare to begin with, and should have prominent discussion on this list. In the case where it's impossible to follow rule #1, it is still critical to write scripts to roll back to the pre-change state. 3. For anything that involves a schema change to the production dbs, make sure Asher Feldman (afeldman(a)wikimedia.org) is on the reviewer list. He's already keeping an eye on this stuff the best he can, but it's going to be easy for him to miss changes in extensions should they happen. I don't have a strong opinion about whether we need to follow rule #1 above through an iteration of our six month tarball release cycle, but we at least need to follow it through the two week deployment cycle. Assuming this seems sensible to everyone, I can update this page with this: http://www.mediawiki.org/wiki/Development_policy (/me desperately tries to avoid yak shaving and updating the policy above for Git) Rob

6 9

Database dump of Bugzilla
by John Du Hart 21 May '12

21 May '12

I'm currently investigating alternative bug tracker and project management software for MediaWiki. To do that I'll be installing some different software on the Labs and importing existing bugs for evaluation by the development team and users. The following software is planned for test: - JIRA <http://www.atlassian.com/software/jira/overview> + Greenhopper + Bonfire - YouTrack <http://www.jetbrains.com/youtrack/> - The Bug Genie <http://www.thebuggenie.com/index.php> - Redmine <http://www.redmine.org/> - ChiliProject <https://www.chiliproject.org/> If you have any suggestions for this list I'd be glad to hear it. Of course, this goes back to the original request. To do this I need a dump of the current Bugzilla install. Is it possible for me to get this and under what conditions? Thank you. -- John

18 43

Jump to page:

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 2012